News Wochenrückblick: Nvidia mit Problemen in DirectX-12-WoW und bei HDR

[Hill Ridge]

Jop. Wie beim Treiber der Async Compute für Maxwell nachreichen sollte . Auf den warte ich immernoch.

Intel ist auch nicht besser.

For Intel CPUs introduced in the past five years, we expect to issue updates for more than 90 percent of them within a week, and the remainder by the end of January.

https://newsroom.intel.com/news/intel-offers-security-issue-update/

 

[EchoeZ]

Nach all den Jahren von DX12 sind die überwiegenden Implementierungen noch immer ein Armutszeugnis

Solange nVidia unter DX1211 besser dasteht, und Intel seine Hochleistungskerne an den Gamer bringen will, wird sich an der stiefmütterlichen Behandlung von DX12 durch die Spiel-Entwickler auch nichts ändern...

 

[.Snoopy.]

Ist schon Schade das nVIDIA den Fortschritt so massiv blockiert. Seit gut zweit Jahren ist das mit dem HDR bekannt. Es scheint auch eher so, dass deren Karten bis auf Kante an DX11 optimiert sind und keine Leistung mehr für DX12 und HDR über hat.
Jetzt können wir nur hoffen, dass nVIDIA in den nächsten Generationen nachzieht damit auch die Entwickler mehr Motivation haben DX12 und HDR einzusetzen. AMD hat hier keine andere Möglichkeit, als zu warten bis der Marktführer sich aus der Vergangenheit in Richtung Heute bewegt.

Meine Befürchtung ist, das nVIDIA hier eine weitere proprietäre Lösung auf dem Markt werfen könnte.

 

[Bard]

Also ich hab die definitive Antwort auf die Frage AMD oder NVidia:

3dfx Voodoo 3 mit AGP Anschluss.

Beste Karte und braucht nicht so n Schnickschnack wie DirectX 11 oder 12.

 

[Locuza]

Hierzu hilft folgendes Video:
AMD vs NV Drivers: A Brief History and Understanding Scheduling CPU Overhead - YouTube

Kurz gesagt: Nvidia setzt seit Kepler auf einen Software-Sheduler, welcher die Probleme von Dx11 angeht und die Threads in Software aufteilt und so den Mainthread entlastet. Dies hilft für höhere drawcalls. Da es jedoch eine Softwarelösungen ist und es das Aufteilen der Threads nicht umsonst gibt, verursacht diese Lösung mehr CPU-Last. Da nicht alle Spiele perfekt skalieren und häufig CPU-Leistung in der Breite brach liegt, sorgt dies in den meisten Fällen für mehr drawcalls. In einem Titel der bereits sehr gut skaliert, oder wenn die CPU zu 100% ausgelastet ist, kann das auch ein Nachteil sein. (Per Definition verursacht also der Nvidia Treiber einen höheren Overhead und nicht der AMD Treiber. Nvidias Lösung entlastet dafür jedoch den Mainthread)

AMD hingegen setzt auf einen Hardwaresheduler (ACE), welcher dies effizienter macht als es ein Software-Sheduler je könnte. Dies benötigt jedoch zwingend eine LowLevel-API, da dieser nicht mit dem Featureset von DX11 umgehen kann. Durch die Hardwarelösung kann AMD dies auch nicht per Software Mal eben wieder ändern.

Mit LL (LowLevel) hat AMD das Problem komplett gelöst, während nvidias Lösung nur ein Workaround für die Probleme einer veralteten API wie DX11 ist. Zudem kommt hinzu, dass bei nvidias Lösung derjenige gewinnt, der am Ende mehr "Menpower" bzw Geld in sein Treiberteam steckt. Wie alle Lösungen von Nvidia also wieder ein proprietärer Ansatz.

Die Entwickler sind also gefangen zwischen dem Marktführer, welcher am liebsten in der Vergangenheit bleibt und dem Underdog, welcher bereits die Lösung bereit hält an der alle ohnehin nicht vorbei kommen.

Keiner der beiden wird von seiner Strategie abweichen da es automatisch eine Stärkung des anderen wäre. Durch die ungleichen Marktanteile ist jedoch der Kunde der Leidtragende, da so Fortschritt zurückgehalten wird.

----------

Viele ignorieren ein weiteres Problem an nvidias Lösung, nämlich, dass diese nur solange gut funktioniert, wie einer der beiden Hersteller diese einsetzt. Wie gesagt ist der Software-Sheduler von nvidia eine Verbesserung der Drawcall-Problematik auf dem Mainthread unter DX11, aber es ist und bleibt eben nur ein Workaround, - ein Tropfen auf den heißen Stein und keine komplette Lösung des Problems. Angenommen AMD würde ebenfalls statt eines Hardware-Shedulers das ganze in Software umsetzen, dann würde dies aller höchstens 1 Jahr Verbesserung versprechen. Danach tuen die Entwickler das, was sie jeher getan haben. Nämlich die Performance von beiden an die Wand fahren. Und man sieht es ja jetzt bereits. Es gibt immer wieder genug Titel die dennoch auch bei Nvidia im CPU-Limit landen. Da sind wir also immernoch weit weit entfernt von den 30k Drawcalls die man aktuell unter Vulkan herraushaut. Wolfenstein 2: The New Colossus - 30 Mal mehr Draw-Calls als in Doom

Das Video hilft leider nicht, sondern hat dazu geführt das in mehreren Foren viele Falschinformationen und Annahmen sich verbreitet haben.

Nvidia setzt nicht seit Kepler auf einen Software-Scheduler, Nvidia hat seit Kepler den Hardware Warp-Scheduler vereinfacht, der keine Hardwarechecks mehr bezüglich der Abhängigkeiten der Instruktionen und dem Register-File durchführt, sondern wo der Treiber diese Information auflöst.
Das hat nichts mit DX11 oder DX12 zu tun, sondern wie die Hardware grundlegend funktioniert.

Seite 10 Kepler Whitepaper:

We also looked for opportunities to optimize the power in the SMX warp scheduler logic. For example,
both Kepler and Fermi schedulers contain similar hardware units to handle the scheduling function,
including:

a) Register scoreboarding for long latency operations (texture and load)
b) Inter‐warp scheduling decisions (e.g., pick the best warp to go next among eligible candidates)
c) Thread block level scheduling (e.g., the GigaThread engine)

However, Fermi’s scheduler also contains a complex hardware stage to prevent data hazards in the
math datapath itself. A multi‐port register scoreboard keeps track of any registers that are not yet ready
with valid data, and a dependency checker block analyzes register usage across a multitude of fully
decoded warp instructions against the scoreboard, to determine which are eligible to issue.

For Kepler, we recognized that this information is deterministic (the math pipeline latencies are not
variable), and therefore it is possible for the compiler to determine up front when instructions will be
ready to issue, and provide this information in the instruction itself. This allowed us to replace several
complex and power‐expensive blocks with a simple hardware block that extracts the pre‐determined
latency information and uses it to mask out warps from eligibility at the inter‐warp scheduler stage.

https://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf

GCN auf der anderen Seite muss dank der Architektur gar nicht auf Abhängigkeiten zwischen den Instruktionen schauen, weder die Hardware noch die Software macht in dem Bezug etwas.
Was ebenso nichts mit einem API-Design zu tun hat, sondern wie die Architektur grundlegend funktioniert und ihre Berechnungen ausführt.

Nvidia unterstützt als einziger Multithreaded Command-Lists über Deferred Contexts bei DX11, dass müssen Spiele aber explizit verwenden.
Und wie genau die interne Treiberarchitektur bei den Herstellern ausfällt und was über mehrere Threads erledigt wird, ist leider nicht offenkundig.
AMD hält die Architektur aber nicht auf, ihre implizite Maschinerie ebenfalls zu verbessern und Multithreaded CLs zu unterstützen.
Und proprietär sind die Treiber so oder so, es kümmert die Entwickler nicht explizit wie die Treiber umgesetzt sind, die DX11 API wird direkt verwendet, nicht die Treiber der Hersteller und die Treiber der Hersteller müssen DX11 konform sein und solange das gewährleistet ist, besitzen alle Hersteller einen entsprechenden Freiraum bei der Umsetzung einer entsprechenden Lösung, egal ob bei der Software oder Hardware.

Die ACEs bei GCN sind Hardware-Scheduler, welche sich aber nur um die Verwaltung von Compute-Queues kümmern können, um Draw-Calls also 3D-Befehle können sie sich prinzipiell nicht kümmern.
Und wenn ein Entwickler keine separate(n) Compute-Queue(s) unter D3D12/Vulkan verwendet, dann werden die ACEs auch nicht unter D3D12/Vulkan benutzt.
Das hat aber auf den CPU-Overhead keinen nennenswerten Einfluss und betrifft primär die GPU.

 

[.Snoopy.]

Also ich hab die definitive Antwort auf die Frage AMD oder NVidia:

3dfx Voodoo 3 mit AGP Anschluss.

Beste Karte und braucht nicht so n Schnickschnack wie DirectX 11 oder 12.

Du weist schon das nVIDIA damals 3dfx in großen Teilen, wenn nicht sogar komplett, aufgekauft hat?

 

[Bard]

Du weist schon das nVIDIA damals 3dfx in großen Teilen, wenn nicht sogar komplett, aufgekauft hat?

Ermordet* und dann die Leichenteile aufgekauft wohl eher.
Aber noch nicht zum Zeitpunkt der Voodoo 3 soviel ich weiß.

 

[.Snoopy.]

Aber noch nicht zum Zeitpunkt der Voodoo 3 soviel ich weiß.

Das ist korrekt, es gab ja noch Voodoo 4 & 5.

Dennoch traurig, wenn man sieht das von den einstigen Pionieren bei nVIDIA alles mit den Jahren verkümmert ist. 3dfx hätte als Firma selbst DX12 schon gefordert, oder zumindest würden diese es versuchen ordentlich zu unterstützen.

 

[Palmdale]

Solange nVidia unter DX12 besser dasteht, und Intel seine Hochleistungskerne an den Gamer bringen will, wird sich an der stiefmütterlichen Behandlung von DX12 durch die Spiel-Entwickler auch nichts ändern...

Ich vermute, Du meintest DX12 als kleinen Typo. Dennoch möchte ich dieser Annahme widersprechen, denn low level beinhaltet, dass das "kümmern" vom Entwickler geleistet werden muss weg von den high level DX11 im Zusammenspiel mit den Treibern von AMD und Nvidia. Blickt man dann auf die Gamesbranche mit ihrer omnipräsenten Knappheit an Zeit und Budget, braucht man lediglich 1 und 1 zusammen zählen, dass das nie seinen Durchbruch erleben wird. Wenn also nur ein Bruchteil der Spiele überhaupt jedes Quentchen Leistung benötigt, wenn DX12 nur in bestimmten Konstellationen überhaupt Vorteile bietet bei sonst gleicher Optik und ich gleichzeitig Gefahr laufe, den Rattenschwanz an Service/Performance/Bugfixing sich einzufangen, sehe ich nicht einen validen Punkt pro low level.

 

[Hardware_Hoshi]

Kurz gesagt: Nvidia setzt seit Kepler auf einen Software-Sheduler, welcher die Probleme von Dx11 angeht und die Threads in Software aufteilt und so den Mainthread entlastet. Dies hilft für höhere drawcalls.

Drawcalls sind nicht das Hauptproblem bei WoW. Das Spiel wurd grässlich für DirectX9 entwickelt und über die Jahre seit 2004 wieder und wieder umgeschrieben. Der Code ist ein einziger Flickenteppich mit unzähligen Fixes und ständigen Patches.

Die jeweilige Performance hat nie lange Bestand. Spätestens bei der nächsten Änderung könnte alles wieder einbrechen. Kennen WoW-Spieler zu Genüge!

Da es jedoch eine Softwarelösungen ist und es das Aufteilen der Threads nicht umsonst gibt, verursacht diese Lösung mehr CPU-Last. Da nicht alle Spiele perfekt skalieren und häufig CPU-Leistung in der Breite brach liegt, sorgt dies in den meisten Fällen für mehr drawcalls. In einem Titel der bereits sehr gut skaliert, oder wenn die CPU zu 100% ausgelastet ist, kann das auch ein Nachteil sein. (Per Definition verursacht also der Nvidia Treiber einen höheren Overhead und nicht der AMD Treiber. Nvidias Lösung entlastet dafür jedoch den Mainthread)

Dieser Mainthread ist jedoch genau der Punkt, den WoW so stark benötigt. Die Engine ist bereits uralt und wurde nie für moderne Multi-GPU entwickelt. Klar gab es hier und da einige ergänzende Tricks, die Blizzard groß als "Performance Improvements" verbucht hat.

Blizz hat einfach immer alles in einen Thread geknallt bis entweder die Spielerseite gelaggt hat ohne Ende oder die Spieleserver aufgrund der Belastung zusammengebrochen sind.

AMD hingegen setzt auf einen Hardwaresheduler (ACE), welcher dies effizienter macht als es ein Software-Sheduler je könnte. Dies benötigt jedoch zwingend eine LowLevel-API, da dieser nicht mit dem Featureset von DX11 umgehen kann. Durch die Hardwarelösung kann AMD dies auch nicht per Software Mal eben wieder ändern.

ACEs haben allerdings die Problematik, dass sie lediglich sehr spezifische Aufgaben und und dazu viel Platz auf der GPU-Die braucht. Mit einer Software-Lösung hat Nvidia diese Problematik nicht und skaliert daher besser mit mehr Shadern. AMD vertraut z.B. darauf, dass die Entwickler und Microsoft Windows die Verwaltung übernehmen und den Radeons die Tasks ideal zuspielen. Passiert selbst mit Low-Lvl nicht.

Die Low-Level API löst diverse Probleme nicht, sondern verdeckt diese lediglich.

Mit LL (LowLevel) hat AMD das Problem komplett gelöst, während nvidias Lösung nur ein Workaround für die Probleme einer veralteten API wie DX11 ist. Zudem kommt hinzu, dass bei nvidias Lösung derjenige gewinnt, der am Ende mehr "Menpower" bzw Geld in sein Treiberteam steckt. Wie alle Lösungen von Nvidia also wieder ein proprietärer Ansatz.

Als ob AMD keine propritären Ansätze hätte. Schau dir nur einmal den Quark an, den die Entwickler für beispielsweise Vega optimieren müssten. Furchtbar!

Die ganze Diskussion wird hinfällig, wenn man bedenkt wie viel schneller Nvidia trotz veralteter DX11-Schnittstelle gegnüber AMD mit DX12 ist. Anstatt dass AMD mehr Manpower in die Softwareentwicklung und Optimierung steckt, lagern sie das in üblicher Manier an die Spieleentwickler ab. Nichts anderes ist der Hype um Low-Lvl APIs. Die Studios müssten jetzt den Part übernehmen, den AMD eigentlich tun sollte. Das diese Entwickler nicht sonderlich begeistert sind, sollte logisch sein.

Die Entwickler sind also gefangen zwischen dem Marktführer, welcher am liebsten in der Vergangenheit bleibt und dem Underdog, welcher bereits die Lösung bereit hält an der alle ohnehin nicht vorbei kommen.

Es heißt, Ergebnisse sprechen für sich. Wir könnten hier den ganzen Tag über theoretische Änderungen reden. Für die Entwickler zählt in erster Linie wie sie ihre Deadlines und Budgets einhalten. Technische Implementierung ist da senkundär. Man muss immehin Spiele entwickeln und hat nicht ewig Zeit für außenstehende Hardware zu optimieren.

World of Warcraft ist seit Jahren im "Cash-Cow" Modus angekommen. Viel Geld wird Blizzard nicht mehr investieren.

Keiner der beiden wird von seiner Strategie abweichen da es automatisch eine Stärkung des anderen wäre. Durch die ungleichen Marktanteile ist jedoch der Kunde der Leidtragende, da so Fortschritt zurückgehalten wird.

Hör auf, das ist kompletter Unsinn! Die Kunden bestimmen die Marktanteile, nicht die Spieleentwickler. Beschwer dich eher bei den Marketingabteilungen, die Vorweg die Ausrichtung für die größere Kundengruppe vorgibt.

Bei einem Marktanteil von aktuell etwas 70:30 würde kein Mensch auch nur auf die Idee kommen ewig für AMD zu entwickeln. Das wäre betriebswirtschaftlicher Unsinn.

Den Fanboy interessiert nicht das bessere Produkt, sondern nur sein Verein. Der Wettbewerb funktioniert im PC Bereich nicht mehr. ... Eines steht fest - Gäbe es mehr Hersteller, hätte sich Low Level viel schneller etabliert. So stellt sich der Marktführer quer und die Lemminge machen mit.

Bei nur zwei Hardwareherstellern kann es niemals vernünftigen Wettbewerb geben. Das Fanboygerede kannst du dir sparen. Und nein, mehr Hersteller würden Low-Level noch mehr verschieben. Immerhin muss man damit auf die spezifischen Hardwareeigenschaften der Hardware "jedes" Herstellers am optimieren.

Eventuell hast du nicht verstanden was Low-Level eigentlich bedeutet.

 

[Ozmog]

Meine Befürchtung ist, das nVIDIA hier eine weitere proprietäre Lösung auf dem Markt werfen könnte.

Da könnte man bald Hoffnung auf Intel setzen, wenn sie tatsächlich in den Grafikkartenmarkt vorstoßen sollten und nicht nur im HPC/GPGPU-Markt damit aufschlagen. Auch wenn ich kein Freund von Intel bin, ganz im Gegenteil sogar, ist eine weitere Marktdiversifizierung sehr Begrüßenswert, insbesondere, wenn es ein weiterer Gegenpol zu nVidia ist. Sollte Intel Grafikkarten anbieten, werden sie bestens auf Freesync setzen können.
Aber bis dahin vergehen noch ein paar Jahre, vor 2021 wird das bestimmt nichts (Eigene Schätzung) und ob Intel das Thema nicht (wieder) an die Wand fährt, bleibt da sowieso noch offen.

 

[Locuza]

Blickt man dann auf die Gamesbranche mit ihrer omnipräsenten Knappheit an Zeit und Budget, braucht man lediglich 1 und 1 zusammen zählen, dass das nie seinen Durchbruch erleben wird. Wenn also nur ein Bruchteil der Spiele überhaupt jedes Quentchen Leistung benötigt, wenn DX12 nur in bestimmten Konstellationen überhaupt Vorteile bietet bei sonst gleicher Optik und ich gleichzeitig Gefahr laufe, den Rattenschwanz an Service/Performance/Bugfixing sich einzufangen, sehe ich nicht einen validen Punkt pro low level.

Es ist vor allem ein zeitliches Problem, welches die DX12/Vulkan-Verbreitung hemmt, deutlich weniger die technischen Designaspekte.
Das war von der grundlegenden Ausgangslage bei DX10 nicht deutlich anders.
DX11 ist praktisch DX10 + Compute Shader, es hat aber etliche Jahre gedauert bis Engines auf das neue API-Design umgestellt worden sind.

Für Entwickler liegen die Vorteile auf der Hand, die Perf/Watt-Vorteile sind bei low-end-devices sehr attraktiv und es gibt viele Bemühungen in Hinsicht auf Android-Spiele.
Für anspruchsvolle Spieletiteln sind die Vorteile bei einer entsprechenden Engine-Architektur auch massiv, nur liegt hier die Krux an der Sache, dass ändert man nicht zügig, vor allem nicht wenn hunderte Entwickler an einer Engine und an Spieleentwicklungen sitzen, wo beides nicht immer völlig synchron abläuft.

id Software hat sich viel Mühe gemacht die id Engine zu restrukturieren und massiv von den neuen APIs zu profitieren.
Sie nutzen es auch aus um Kosten zu sparen bzw. die Content-Erstellung zu beschleunigen, die Draw-Calls sind so günstig das die Artist bei Wolfenstein 2 nicht ständig darauf aufpassen mussten, wie ihr Geometrie-Budget aussah.

 

[Palmdale]

@Locuza

Dem Grunde nach richtig, nur hat id Software selbst bei ihrer eigenen Engine recht lange gebraucht, das in Wolfenstein halbwegs hinzubekommen. Dieses Budget haben mMn niemals Dritte Entwickler und selbst die großen Publisher setzen wieder seltener auf DX12. Quo vadis ll?

 

[Locuza]

@Palmdale

Definiere dritte Entwickler und ich kenne keinen großen Publisher der wieder seltener auf DX12 setzt.
Oder ist ein Entwickler bekannt der am Anfang X-Engine verwendet hat mit DX12-Support und jetzt nicht mehr?

 

[Wadenbeisser]

Die ACEs bei GCN sind Hardware-Scheduler, welche sich aber nur um die Verwaltung von Compute-Queues kümmern können, um Draw-Calls also 3D-Befehle können sie sich prinzipiell nicht kümmern.
Und wenn ein Entwickler keine separate(n) Compute-Queue(s) unter D3D12/Vulkan verwendet, dann werden die ACEs auch nicht unter D3D12/Vulkan benutzt.
Das hat aber auf den CPU-Overhead keinen nennenswerten Einfluss und betrifft primär die GPU.

Mit anderen Worten die ACEs füttern die Shader, welche wiederum auch beim Rendern der Spiele zum Einsatz kommen?

 

[Hill Ridge]

Es scheint auch eher so, dass deren Karten bis auf Kante an DX11 optimiert sind und keine Leistung mehr für DX12 und HDR über hat.

Die aktuellen GPUs von NVIDIA basieren alle noch auf G80, das war halt nie für DX12 ausgelegt.
NVIDIA müßte da schon eine neue Architektur entwickeln.

 

[feidl74]

ich glaube die Probleme von nvidia mit dx12 in wow liegen auch an der tollen technischen Umsetzung seitens Blizzard. ich habe mit aktivierter igpu und 1070 gtx immer nur 24fps, egal welche Auflösung, welche Settings in dem grafikmenü von wow eingestellt sind. selbst wenn ich nur die gtx auswähle(system-erweitert) habe ich 24 fps. deaktiviere ich die igpu des 7600k, siehe da, dann habe ich ingame auf einmal konstante 60fps. auch bei der Umsetzung von dx 11, damals mit cataclysm gabs blizzardgemachte Probleme z.b. mit den high end karten von amd/nvidia. da hatte man in manchen gebieten einfach nur nen schwarzes loch auf der map und konnte die gebiete nicht betreten. oder artefaktbildung in sw, die ersten tage(z.b. verschobene fensterrahmen der häuser)

 

[frkazid]

Die Customs drehen Kreise um diese Karte.

Haste mal ne Quelle?

 

[Locuza]

@Wadenbeisser

Ja.
Im Prinzip liegt seit GCN eine feinere Trennung der Hardware-Scheduler vor.
Früher wie auch jetzt gab es einen Graphics Command Processor der sich um die ganze Verwaltung der Befehle von dem PCIe-Bus über die Host-CPU gekümmert hat und entsprechend alle Arbeitsaufgaben verteilt hat von Pixel, Vertex, Geometrie, Compute-Shader etc.

Die ACEs sind zusätzliche Hardware-Scheduler (Bei GCN1 nur zwei fixe Compute-Pipes, ab GCN2 ein bis zwei komplexere Compute Engine Blöcke), welche sich nur um die Verwaltung von Compute-Queues und entsprechender Befehle kümmern.

Bei DX12/Vulkan besteht die Möglichkeit Compute-Queues zu verwenden, der Vorteil für die Software/Hardware ist, dass der Entwickler seine Befehle vorsortiert hat und die Abhängigkeiten definiert, entsprechend kann die Hardware die Arbeitslast leichter verwalten.
Ohne Compute-Queues landen alle Befehle in einer Universal-Queue und werden mit weniger Freiheit abgearbeitet und je nach Hardware/Sicherheit seriell verwaltet.
Unter DX11 kümmert sich der Treiber um die Erstellung der Queues und um die ACEs zu verwenden, müsste AMD wohl relativ komplexe Analysen und spezifische Spieleprofile anlegen, um das robust umzusetzen.

Ganz analog hat auch Nvidia Hardware-Scheduler, die sich um die Verwaltung unterschiedlicher Queues kümmern und wo die Befehle letztendlich auf die Hardware verteilt werden.
Die Sache mit den Schedulern dürfte eher nicht ausschlagend sein, sondern die eigentliche Arbeitsweise der State-Machine.

Bei GCN hat AMD viel generalisiert und die Compute-Units berechnen und speichern viele Dinge über die allgemeine Register/Speicher-Hierarchie, wo früher häufig Fixed-Function-Hardware für spezifische Funktionen zuständig war und extra Dinge gesetzt werden mussten.
AMDs CUs können sowohl Compute, als auch 3D-Aufgaben auf einer Recheneinheit verwalten und günstig zwischen den Aufgaben wechseln.
Bei Nvidia scheint das nicht so fein zu arbeiten, da kann nur ein 3D- oder Compute-Kontext pro Compute-Unit verwaltet werden und der Zustand der Maschine muss geändert werden, wenn man den Aufgabentyp wechseln möchte.
Bei Fermi-Maxwell geschieht so ein Context Switch sehr langsam und das Scheduling war statisch, ab Pascal kann Nvidia dynamisch verwalten und ein Context Switch funktioniert deutlich zügiger.
Bei Fermi-Maxwell verwaltet die Hardware auch keine separaten Compute-Queues, Treiber und/oder die DX-Runtime packen alle Draw/Dispatch-Befehle in eine Universal-Queue, bei den GPUs ist es effektiv egal, ob ein Entwickler Compute-Queues verwendet oder nicht, dass Ergebnis müsste nahezu das gleiche sein.

 

[Shrimpy]

Und wenn schon, wenn Nvidia generell eh 15-20% schneller ist, dann gleicht sich das aus. Aber das wird Nvidia nicht lange auf sich sitzen lassen, denke mit dem nächsten Treiber sieht das ganz anders aus.

In Anbetracht von Maxwell1 und dem "kommenden" Async Patch ein Witz.
Ungefähr so wie das Vega unter Fine Wine fällt.

Ergänzung (22. Juli 2018)

Jetzt können wir nur hoffen, dass nVIDIA in den nächsten Generationen nachzieht damit auch die Entwickler mehr Motivation haben DX12 und HDR einzusetzen.

Maxwell3, ÄH Turing wird auch nur eine DX11 schleuder, erst Volta wird wohl bessere DX12 Kompatibilität bringen.