AMD Vega 10: Linux-Patch nennt weitere technische Eckdaten

[Locuza]

[...]
Weder Vulcan noch Mantel sind der Grund für Dx12 als Lowlevel-Api. Lowlevel Api sind halt einfach wieder "in mode" obwohl sie gewaltige Nachteile haben.
Lustigerweise ist es OpenGL das heir Vorreiter ist - und dann behaupten leute auchnoch Vulkan sei die Weiterentwicklung....

Für Modeerscheinungen kommt kein Industriegremium zusammen, um etwas für die nächste Dekade als Standard zu spezifizieren.
Natürlich hat alles seine Vor- und Nachteile, Vulkan und DX12 sind weitere Tools in der Entwicklung, welche Probleme adressieren, die vorherige APIs nur noch suboptimal erfüllen (werden).
Wo war übrigens hier OGL der Vorreiter? Auf AZDO-Folien und einer Implementierung die nur bei Nvidia robust funktioniert?

Auch Hat nvidia ganz normal Dx12 in Hardware - sonst würde das ganze nicht wirklicch rund Laufen. Nur es gibt eben dafür verschiedene Ansätz. So hat zB AMD Async-Compute mehr als nur ein bisschen gehyped - denn im Grunde ist es ncihts anderes als eine Entschuldigung das ganze Scheduling den Software-Entwicklern auf den Hals zu brummen. Und bei nvidia? ja, sie haben ganz normal Dx12 Async Compute in Hardware - schon seit viele Generationen. Nur eben wird hier auf einen anderen Ansatz gesetzt: Die GPU wird von haus aus vollkommen ausgelastet und das Scheduling von Graphic- und Compute-Workloads funktioniert einwandfrei. Nur wenn dann ein programm auf die idee kommt das ganze Scheduling über den haufen zu werfen und einfach fröhlich drauf los dauerhaft context-switches durchführt dann leidet die Leistung unter der grotten schlechten Programmierung.

Ist es nicht, es ist ein Konzept welches dem Entwickler hilft seinen Workload näher zu spezifizieren und der GPU dabei helfen kann den Workload besser einzuteilen, mit Prioritätsmarkern ist auch mehr Kontrolle über den Arbeitsablauf möglich.

Die GPUs bei Nvidia sind typischerweise besser ausgelastet, aber nicht vollständig und teilweise auch nicht, weil eben das Hardwaredesign limitiert.
Auch Nvidia verwendet Fixed-Function-Hardware für das Rendering und besitzt mehrere interne States, Anwendungen belasten unterschiedliche Hardwareteile, wenn der Entwickler spezifiziert du kannst im Zeitraum x 3D und Compute wie es dir beliebt verwalten, dann kann das potentiell bei jedem die Idle-Times kürzen, Voraussetzung ist natürlich ein flexibles Scheduling-Model, welches die Hardware selber unterstützen muss.
Kepler und Maxwell tun es nicht, die ignorieren die zusätzlichen Compute-Queues und vereinfachen das Scheduling indem wieder alles in die 3D-Queue gepackt wird.
Pascal führt aber Dynamic-Load-Balancing und Pixel/Instruction-Level-Preemption ein, jetzt funktioniert das Konzept auch unter Nvidia.

Von Nvidia selber auf der GDC im März 2017:
GDC: NVIDIA betont die Vorteile von Async Compute - Hardwareluxx

Ist das selbe wie auch mit den "Vulkan/Dx12 können soooo viele drawcalls" bullshit.
In wlechem fall bringt sowas einen Vorteilß Ach ja - nur wenn gegen jede Vernunft alles von CPU-seiten her gemanaged wird, der Hardware-scheduler umgangen und jedes einzelne Objekt als drawcall gesendet wird. leistungstechnisch ein Abltraum da man nicht nur eine vorhande Hardwarefunktion in Software implementiert sondern die ganzen daten nun auchnoch von der Cpu zur GPU gestreamed werden müssen.

In jedem Fall, wo die CPU schwach ausfällt und in einer Welt, wo wir stärkere GPUs besitzen, uns mehr Objekte leisten können und nicht alles zwanghaft instancen müssen, damit der Overhead nicht explodiert.

Fiji done right reicht aber wohl eben nicht AMD

Wenn das Ding genau aufgebaut ist wie schon 2015 Fiji, wenn auch inklusive GCN 5/1.4 und wir sogesehen nur auf 14nm gesprungen sind, wieso ist das Ding von 596mm² nur auf knapp unter 500mm² gesunken?
Das einzige was ich mir spontan denken kann, ist das VEGA seine Rohleistung dank Neuerungen weitaus besser auf die Straße bringen kann... als Fiji und co und man deswegen wenig mehr Rohleistung braucht?

Reuse - Reduce - Recycle:

Bei der gleichen Packdichte wie bei Polaris 10 wäre Fiji ~ 360mm² groß.

Hawaii (GCN Gen 2): 14,2 Millionen Transistoren pro mm² (6,2 Mrd. Transistoren / 438mm²)
Tonga (GCN Gen 3) : 13,9 Millionen Transistoren pro mm² (5 Mrd. Transistoren / 359mm²)
Fiji (GCN Gen 3): 14,9 Millionen Transistoren pro mm² (8,9 Mrd. Transistoren / 596mm²)
Polaris 10 (GCN Gen 4): 24,4 Millionen Transistoren pro mm² (5,7 Mrd. Transistoren / 234mm²)

Eher kleiner, da Fiji eine höhere Packdichte erreicht hat, als andere GCN-Chips.

Was könnte Vega 10 so aufpumpen im Vergleich zu Fiji?
Ein paar Dinge aus folgendem Menü:

Von Gen 4:

- Instruction Buffer sind größer geworden
- Intstruction Prefetch wird unterstützt
- Primitive Discard Accelerator
- Die Geometry-Engines puffern jetzt die meshes selber, nicht mehr der L2$.
- Die verbesserte Delta-Color-Compression

Von Gen 5:

- Draw-Stream-Binning-Rasterizer
- Der Rasterizer wird nun auch Conservative Rasterization unterstützen
- Die Instruction Buffer werden erneut vergrößert
- Die ALUs sollen eine höhere Taktrate unterstützen
- Die ALUs werden Double-Rate FP16 unterstützen, aktuell ist es nur Single-Rate und vermutlich ist vierfach Int8 auch etwas neues, was GCN Gen 4 noch nicht konnte
- Die Geometry-Engines werden den theoretischen Durchsatz von einem Dreieck auf 2,75 erhöhen (liest sich krude, gilt vielleicht nur für spezielle Fälle), was insgesamt 11 Dreiecke pro Takt bedeutet, anstatt 4 wie bei Fiji.
- Die ROPs sind nun die Clients vom L2$, weswegen AMD möglicherweise auch Rasterizer Ordered Views unterstützt, es könnte sein das deswegen der Flächenbedarf steigt.
- Da der Rasterizer jetzt Kacheln im L2$ speichert und auch die ROPs die Konsumenten vom L2$ sind, wird die Kapazität vom L2$ garantiert steigen, vermutlich von 2MB auf 4MB.
- Und AMD hat noch mehr Dinge getan, die aktuell noch nicht genannt wurden.

 

[Casurin]

Auf AZDO-Folien und einer Implementierung die nur bei Nvidia robust funktioniert?

Das OpenGl bei AMD nicht so gut läuft ist nicht schuld der Api.......

Ist es nicht, es ist ein Konzept welches dem Entwickler hilft seinen Workload näher zu spezifizieren und der GPU dabei helfen kann den Workload besser einzuteilen, mit Prioritätsmarkern ist auch mehr Kontrolle über den Arbeitsablauf möglich.

Da hast du was am prinzip von Async missverstanden denn ist dafür konzepiert den Programmfluss unabhängig vom Scheduler zu manipulieren - aka den aktuellen Workload zu unterbrechen und etwas anderes ausführen das eben nciht üebr prioritäten vom Scheduler eingereiht wurde.

Die GPUs bei Nvidia sind typischerweise besser ausgelastet, aber nicht vollständig und teilweise auch nicht, weil eben das Hardwaredesign limitiert.

Wenn man sich die Uaslastung wirklich ansieht kommt man durchaus auf über 95% auslastung, da ist dann ncihtmehr viel zu holen.

wenn der Entwickler spezifiziert du kannst im Zeitraum x 3D und Compute wie es dir beliebt verwalten, dann kann das potentiell bei jedem die Idle-Times kürzen, Voraussetzung ist natürlich ein flexibles Scheduling-Model, welches die Hardware selber unterstützen muss.

das ist bereits der Fall. Wie geasgt -Async hat damiot wenig zu tun denn es ist für workloads die NICHT gescheduled werden.

Von Nvidia selber auf der GDC im März 2017:
GDC: NVIDIA betont die Vorteile von Async Compute - Hardwareluxx

nvidia 2016, GTX 10xx serie, Seite 15 - Load balancing.
Wenn also die Tasks normal an den Scheduler geschickt werden wird das ganze automatisch gemacht.
Mit Async-compute liegt dies aber dann eben nciht in der hand der GPU oder des Treibers sondern wird allein vom userspace also dem ausführenden Programm bestimmt.

~-der Rest-~

Ein Teil wird auch durch das breitere Speicherinterface kommen - vega soll deutlich mehr Speicher ansprechen können. Mehr Adressen und eine breitere Anbindung kosten auch genug Platz.

 

[Pu244]

Ich weiß nicht was die Leute haben. Wenn es so kommt, dann wird Vega 10 um etwa ein Drittel oder sogar noch mehr, schneller sein als die Fury X, von daher wird man über der GTX 1080 herauskommen. Wichtiger sind andere Fragen, vorallem wie es sich mit den Produktionskosten verhält, das hat der Fury X ja neben dem geringen Speicher und der Wakü ja das Genick gebrochen. Das bringt uns zu der Frage ob die Karten wieder solche wassergekühlten Monster werden, die dann kaum einer kaufen möchte.

...und da stellen wir die gleiche Frage wie schon gestern: Wer sind die Kunden hierfür, nachdem seit dem Pascal-Release fast ein Jahr vergangen ist?

Grakas werden kontinuierlich neugekauft, die Käufer verabreden sich nicht alle weltweit, um alle paar Jahre auf einen Schlag mehrere duzend Millionen Grakas zu kaufen. Die meisten kaufen, wenn sie ein Bedürfnis spüren, die wenigsten warten längere Zeit ab und kaufen dann. Von daher wird Vega, wenn der Preis stimmt, definitiv Käufer finden.

 

[DarkSoul-7]

... was selten effizient ist und meist von sehr schlechtem Code-design zeugt - genauso wie bei CPUs das dauerhafte nutzen von Interrupts.

Wie willst du denn sonst Zeitkritische Tasks lösen?
Asynchrone Kommunikation?
Irgendwelche watchdogs?

Da braucht es sehr wohl Interrupts

Greez
Soul

 

[Unrockstar85]

Der Artikel hier liest sich noch so als hätte Vega mehrere wichtige Verbesserungen gegenüber Fiji: Alles uber AMD Radeon RX Vega: Technische Daten, Release, Raven-Ridge-APUs [Update]

Auf einmal bläst man ins andere Horn und verbreitet "News" zu angeblichen Benchmarks und fehlenden Verbesserungen gegenüber Fiji.

Ich glaub es gibt einfach jede Menge Frust in der Branche weil AMD so lange keine neuen Infos raus rückt.

Oder aber dass Redaktionen die Größten Fanboys ever sind und auf AMD Hass haben weil man ihnen nur 72Std zum Benchen gibt
Wie man von AMDs Radeon Instinct mit 12,5TFlops auf diesen Bench kommen mag, versteh ich allerdings auch nicht

Vermutlich kommt die Consumer Vega mit 24GB GDDR3 Ram weil der noch günstig rumlag

 

[AfFelix]

wann wurden die 14Nm bei Globalfoundries bestätigt ?

___

einfach verlesen

 

[IngenieursLP]

wann wurden die 14Nm bei TSMC bestätigt ?

Polaris und Vega werden bei Globalfoundries gefertigt. in 14nm.
Und deren Fertigungslizenz haben die meines wissens von Samsung.
Ist auch kein all zu guter Prozess. Der von TSMC ist besser aber auch teurer

 

[AfFelix]

upsala verlesen
habs korrigiert aber wann ist Bestätigt worden das Vega in 14 nm kommt,
muss voll an mir vorbei gerauscht sein.

Edit habe die Amd Präsentationsfolie gefunden

 

[IngenieursLP]

Die meisten kaufen, wenn sie ein Bedürfnis spüren, die wenigsten warten längere Zeit ab und kaufen dann. Von daher wird Vega, wenn der Preis stimmt, definitiv Käufer finden.

AMD kann mich als erster Käufer einer Vega GPU in ihre Geschichtsbücher eintragen

 

[PRShaddix]

Wollen wir nicht auch darüber diskutieren wie daneben Nvidia's Behauptung die 1080 sei schneller als 2 980er tatsächlich war? Von dem "Pascal = 10x Maxwell" Schwachsinn reden wir gar nicht. Oder einigen wir uns doch darauf, dass Herstellerangaben generell Kirschenpickerei sind und dass die Anzahl bestimmter GPU-Bestandteile kein Indiz für einen Die-Shrink ist?

Als AMD damals 2x480>=1080 Vergleich brachte, wusste lustigerweise keiner mehr von Nvidia's Behauptung die 1080 sei schneller als 2 980er Auch wenn die 480 nicht ganz 980 Niveau schafft, war mir damals eigentlich sofort klar, worauf AMD anspielt.

 

[Casurin]

Wie willst du denn sonst Zeitkritische Tasks lösen?
Asynchrone Kommunikation?
Irgendwelche watchdogs?

Da braucht es sehr wohl Interrupts

Greez
Soul

Hier geht es um Grafikberechnungen - da gibt es wenig bis garnichts das zeitkritischer als per Frame basis ist.
Und mit Interrupts - ja, manche Sachen brauchen Interrupts das bestreitet ja auch keiner - entsprechen werden dort auch interrupts eingesetzt. Aber wenn man dauerhaft Interrupts wirft weil zB ein neues bit an den Audio-ADC gesendet werden soll dann hat man etwas flasch gemacht.

 

[Unrockstar85]

Als AMD damals 2x480>=1080 Vergleich brachte, wusste lustigerweise keiner mehr von Nvidia's Behauptung die 1080 sei schneller als 2 980er Auch wenn die 480 nicht ganz 980 Niveau schafft, war mir damals eigentlich sofort klar, worauf AMD anspielt.

Weisst du doch: Was Interessiert mich das Gewäsch von letzen mal.. Ich sag dazu immer wieder nur GTX 970 3,5; Holzkarten; Datensammelwut oder eben diese Aussage 1080 ist soschnell wie zwei 980er
Naja manche Leute glauben auch, nur weil GK104 High End Preise hatte, war es ein High End Chip..

 

[VikingGe]

@Casurin die neuen APIs bieten keine Garantien, wann und wie Jobs auf den Compute-Queues ausgeführt werden, und niemand zwingt Nvidia dazu, sofort sämtliche Arbeit einzustellen, wenn man einen Job an eine Compute Queue sendet. Das einzige, was die Compute Queues garantieren, ist, dass die Jobs auf den Queues keine Fixed Function-Einheiten benutzen.

Im Grunde steht das auch gleich im zweiten Absatz des "Asynchronous Compute"-Abschnitts des von dir verlinkten Whitepapers:

The first scenario involves overlapping workloads. Certain types of workloads do not fill the GPU completely by themselves. In these cases there is a performance opportunity to run two workloads at the same time, sharing the GPU and running more efficiently—for example a PhysX workload running concurrently with graphics rendering.

Und spätestens hier wird auch deutlich, dass das, was NV da beschreibt, an sich nicht viel mit den Compute-Queues von Vulkan/Dx12 innerhalb einer Anwendung zu tun hat, sondern generell mit dem Job-Scheduling auf der Grafikkarte. Pascal kann bei Bedarf so ziemlich jeden Job jederzeit unterbrechen. Mehr steht da nicht.

Vulkan definiert zwar durchaus sowas wie Queue-Prioritäten, wodurch man das auf Anwendungsebene durchaus ausnutzen könnte, aber a) wird seitens der Spezifikation kein Scheduling-Verhalten erzwungen (sprich: Treiber kann mehr oder weniger machen, was er will), und b) hat man im Normalfall (normales Spiel auf 2D-Bildschirm) auch keinen Grund, mehr als eine Graphics-Queue und mehr als eine Compute-Queue zu verwenden und der Compute-Queue eine höhere Priorität zu geben als der Graphics-Queue. Den Grund hast du selbst genannt, es gibt nichts zeitkritischeres als Per-Frame-Operationen. Und wenn der Treiber unter den Umständen trotzdem das langsamere Verhalten wählt, dann ist das nicht meine Schuld.

 

[Casurin]

@Casurin die neuen APIs bieten keine Garantien, wann und wie Jobs auf den Compute-Queues ausgeführt werden, und niemand zwingt Nvidia dazu, sofort sämtliche Arbeit einzustellen, wenn man einen Job an eine Compute Queue sendet. Das einzige, was die Compute Queues garantieren, ist, dass die Jobs auf den Queues keine Fixed Function-Einheiten benutzen.

Und weiter? Damit sit die Grafikkarte ausgelastet - oder mögtest du jetzt unabhängige Arbeiten auf der GPU berehcnen während ein Spiel läuft und dies nochdazu in der sleben Engine unterbringen damit du überhaupt mit Async-Compute eingreifen kannst?!?!

Den Grund hast du selbst genannt, es gibt nichts zeitkritischeres als Per-Frame-Operationen. Und wenn der Treiber unter den Umständen trotzdem das langsamere Verhalten wählt, dann ist das nicht meine Schuld.

Uhm.. du bermerkst aber schon das wenn du den Render-thread aufhalten würdest um einen Compute-Task asuzuführen das das ganze dadurch um rein garnichts schneller abgearbeitet wird und im besten Fall einfach nur die Reihenfolge der Ergebnisse geändert wird? Im nschlimmsten Fall wird die Berechnung des Bildes verzögert und man verliert einen Frame..... soviel zu zeitkritisch.

Es ging darum ob auf nvidia karten Async COmpute möglich ist bzw ob dies Eprfromaze-vorteile bringt. Und die Antworten dazu sind klar 1-ja und 2-nein.
Es können bereits auch so mehrere Utnerschiedliche Threads gleichzeitig auf der GPU ausgeführt werden. Dx12 Async ist nur dafür da um nochmals in einen bereits Laufenden Thread einzugreifen und diesen durch einen anderen zu ersetzen.

 

[Ampre]

Ich bin dafür das der Redakteur Mal eine GPU Kurs besucht.

Wenn man die Zahlen anschaut könnte man wirklich meinen es ist Fiji, aber das ist falsch, denn es hat sich viel im Detail dafür getan. Man hat den Rasterizer umgebaut der mit 11 Polygonen pro Takt mehr raushaut als Nvidia. Nvidia kann nur 7 Polygonen pro Takt raushauen. Siehe hierzu folgenden Link.

http://techreport.com/r.x/2017_03_08_Nvidia_s_GeForce_GTX_1080_Ti_graphics_card_reviewed/B3Dpoly.png

Interessant ist das noch kein Hardwaretester von der Rasterizer Schwäche von Gp102 (1080TI) zu Gp104 (1080) berichtet hat. Da ist GP104 nämlich gleich auf mit GP102, obwohl GP102 zwei Rasterizer mehr hat und folglich mehr Durchsatz haben soll.

Nvidia's GeForce GTX 1080 Ti graphics card reviewed - The Tech Report - Page 3

Zurück zu Vega:
Hinzu kommen die ganzen Änderungen am Speicherinterface selbst
sowie die Integration der Infinity Fabric und das neu Cache Layout.
Die Schader von Fiji waren übrigens hervorragend mit 1000 MHZ kann man in Shaderlastigen Spielen auch gerne Mal die 1070 und 1080 ärgern. Warum sie also nicht so übernehmen?

Man Man Man........

 

[Ampre]

Fachwissen engt nicht ein. Es erweitert den Horizont! Wie will man denn das große ganze Beschreiben wenn man die Details nicht kennt? Alles ist abhängig auf der GPU

Das ist übrigens das Hauptproblem der Wissenschaft zurzeit, die sich selbst nicht so sicher sind ob Einstein richtig liegt mit der Relativitätstheorie. Weil eben das große ganze nicht zu den kleinen Details passt.

Posfaktische Zeiten sag ich da nur. Wo Mutmaßungen mehr zählen als Fakten.

P.s. es wäre nett wenn du mein Zitat aktualisierst. Das erste war zu hart und ich entschuldige mich hiermit beim Redakteur. Die Kritik bleibt aber.

 

[Unrockstar85]

@Ampre:
Machs wie ich. Mach /ignore Titanultra, und der Tag wird schöner.. Don`t feed the Troll sag ich dazu nur
Wie Scriptor Isador sagte: Wissen ist Macht, behütet es gut
Und danke für den Link

 

[Rollora]

Nah, dass hätte Ressourcenverschwendung dargestellt.
Ein Projekt mit der Brechstange, welches Männer, Geld und Zeit bindet und dann ein Jahr später durch Vega direkt ersetzt wird?
AMD hat nicht die Mittel dafür, wenn sie schon jetzt nur wenige Chips über Marktsegmente und Jahre verteilen müssen.

Hmm ok vielleicht, aber:
Nach 1 Jahr einen neuen Chip auflegen ist jetzt keine Kostenfalle, das müssen sie sowieso tun.
Dafür hätten sie im Bereich über 250€ angreifen können. Ein hypothetischer doppelt so großer P10 Chip hätte knapp die doppelte Leistung haben können udn wäre in Gefielden der 1080 unterwegs gewesen. In diesem Preisbereich - oder aufgrund des Verbrauchs meinetwegen auch drunter - hätte man durchaus einen Chip platzieren können.
Nvidia lacht mit ihren 2 Mrd Umsatz doch nur, weil AMD ihnen den Markt über 200€ völlig über gelassen hat und darunter teilt man sich den.

Ich bin dafür das der Redakteur Mal eine GPU Kurs besucht.. Der hat 0 Ahnung von GPUs.

Es fällt mir leider allgemein auf, dass man in den Techmedien nicht mehr davon Ahnung haben muss, worüber man berichtet...

 

[Locuza]

Das OpenGl bei AMD nicht so gut läuft ist nicht schuld der Api.......

Irgendwie muss man eine API implementieren und je nach Spezifikation wird diese Aufgabe eben leichter oder schwerer ausfallen.
OGLs Geschichte ist voll mit Fehlern bei der Spezifizierung und Herangehensweise und allgemein ist es natürlich eine implizite API, welche die Verantwortung auf den Treiber schiebt.
AMD hat natürlich nur wenig in ihren OGL-Treiber investiert, aber es ist nicht das einzige Unternehmen, deren OGL (ES)-Treiber zu wünschen lassen, praktisch jeder Hersteller hat Probleme damit OGL robust und performant und dann noch zusätzlich sinnvolle Erweiterungen zu unterstützen.

Da hast du was am prinzip von Async missverstanden denn ist dafür konzepiert den Programmfluss unabhängig vom Scheduler zu manipulieren - aka den aktuellen Workload zu unterbrechen und etwas anderes ausführen das eben nciht üebr prioritäten vom Scheduler eingereiht wurde.

Als Entwickler musst du natürlich generell deine Draw- and Dispatch-Befehle vernünftig einteilen, damit deine GPU nicht die ganze Zeit ihren State wechselt (Was je nach Architektur unterschiedlich schnell vonstatten geht und getriggert wird), der Treiber und die HW managen dann den Ablauf.
Mit Multi-Engine (DX12) kommt die Möglichkeit hinzu unterschiedliche Queue-Typen zu definieren und mit Prioritäten zu versehen.
Synchronization and Multi-Engine (Windows)

Bei gleicher Priorität wird letztendlich nur ein Zeitfenster definiert, ab welchem zusätzlich Command-Lists von der Compute-Queue ausgeführt werden können und ab wann die Berechnungen zu Ende sein müssen.
Vernünftig eingereiht liefert das der GPU nur ein genaueres Arbeitsmodell, welches sie potentiell ausnutzen kann.

Kommen Prioritätsmarker hinzu wird die GPU dann zusehen, gewisse Arbeitsabschnitte vor anderen auszuführen, wobei es auch auf die GPU ankommt, wie schnell reagiert wird und wie teuer das ganze ausfallen wird.

Wenn man sich die Uaslastung wirklich ansieht kommt man durchaus auf über 95% auslastung, da ist dann ncihtmehr viel zu holen.

Time Spy bekommt bei einer GTX 1080 7% hin:
Time Spy: 19 Grafikkarten im 3DMark fur DirectX 12 im Vergleich (Seite 3) - ComputerBase

Was man bei Time Spy auch sieht, dass es Maxwell egal ist, ob Multi-Engine mit einer zusätzlichen Compute-Queue verwendet wird oder nicht, die Resultate fallen identisch aus.


Konkrete Spiele erreichen (aktuell) nicht das Niveau von Time Spy (auch nicht unter Radeons).

Sniper Elite 4 nur 2% (Es sind auch nur 3% bei Radeons):
Sniper Elite 4 Benchmark: Schneller mit DirectX 12 – immer! - ComputerBase

Gears of War 4 auch nur 2% (Gegenüber 7-9% bei Radeons):
Gears of War 4 Benchmark: Eine uberraschend gute PC-Version mit UWP (Seite 2) - ComputerBase

nvidia 2016, GTX 10xx serie, Seite 15 - Load balancing.
Wenn also die Tasks normal an den Scheduler geschickt werden wird das ganze automatisch gemacht.
Mit Async-compute liegt dies aber dann eben nciht in der hand der GPU oder des Treibers sondern wird allein vom userspace also dem ausführenden Programm bestimmt.

Automatisch nacheinander, wobei das Bedürfnis besteht die Auslastung zu erhöhen, indem zusätzliche Aufgaben eingereiht werden, die andere Flaschenhälse aufweisen:
https://image.slidesharecdn.com/hodesstephandirectx12andvulkan-150820145027-lva1-app6892/95/dx12-vulkan-dawn-of-a-new-generation-of-graphics-apis-23-638.jpg?cb=1440082493

Nvidia schreibt es ja selber in ihrem Whitepaper:

For overlapping workloads, Pascal introduces support for “dynamic load balancing.”

In Maxwell generation GPUs, overlapping workloads were implemented with static partitioning of the GPU into a subset that runs graphics, and a subset that runs compute.
This is efficient provided that the balance of work between the two loads roughly matches the partitioning ratio.
However,if the compute workload takes longer than the graphics workload, and both need to complete before new work can be done, and the portion of the GPU configured to run graphics will go idle.
This can cause reduced performance that may exceed any performance benefit that would have been provided from running the workloads overlapped.

Hardware dynamic load balancing addresses this issue by allowing either workload to fill the rest of the machine if idle resources are available

Bei AMD kümmern sich die ACEs bzw. die MEC (Micro Engine Compute) um die Compute-Queues und das Scheduling an die Compute-Units.
Die Compute-Queues und Synchronisationspunkte müssen aber eben vorher definiert werden.

 

[schmed]

Hmm ok vielleicht, aber:
Nach 1 Jahr einen neuen Chip auflegen ist jetzt keine Kostenfalle, das müssen sie sowieso tun.
Dafür hätten sie im Bereich über 250€ angreifen können. Ein hypothetischer doppelt so großer P10 Chip hätte knapp die doppelte Leistung haben können udn wäre in Gefielden der 1080 unterwegs gewesen. In diesem Preisbereich - oder aufgrund des Verbrauchs meinetwegen auch drunter - hätte man durchaus einen Chip platzieren können.
Nvidia lacht mit ihren 2 Mrd Umsatz doch nur, weil AMD ihnen den Markt über 200€ völlig über gelassen hat und darunter teilt man sich den.Es fällt mir leider allgemein auf, dass man in den Techmedien nicht mehr davon Ahnung haben muss, worüber man berichtet...

Sehe ich zu 100% wie Du . Eine 16/14 nm Maske soll ca 12 Mio kosten, einfach den Polaris doppeln und gut ist Amd gibt doch immer ihre guten Baukasten-Möglichkeiten in der Konsolen Sparte an, nicht 1 Jahr nix machen im Gpu Sektor. Manpower ist auch so ne Sache den Chip vom Entwurf zum Tape Out bringen macht Amd auch nicht mehr selbst.


http://www.gsaglobal.org/events/2012/1107/docs/slft2012_wei.pdf

AMD holt Synopsys fur 16, 14 und 10 Nanometer Finfet ins Boot