Test World of Warcraft: DirectX 12 macht AMD schneller, Nvidia bricht ein

[Wadenbeisser]

@Kobura
Ich sehe ohnehin keinen Sinn darin sich wegen der Unzulänglichkeiten für etwas zu verrenken was bereits den Fallback Status besitzt denn für aktuelle APIs wie DX12 und Vulkan ist es überflüssig oder gar hinderlich.
Das sollte man eher aussitzen anstatt darin Zeit und Geld zu verbraten.

 

[Locuza]

Stimmt so aufgrund der Batch Queue Size und den Cache Sizes bei GCN leider nicht. Polaris und Vega wurden hinsichtlich dessen etwas erweitert, sind aber noch lange nicht so umfangreich, dass man wie bei nVidia mehrere Worker Threads größere Batches erstellen lassen könnte. GCN bleibt daher weiterhin effizienter, wenn man viele kleinere Batches direkt über den Main-Thread erstellt und an den Scheduler abgibt.
Dadurch kann GCN einfach nicht so gut mit diesem Programmiermodell skalieren, da der Overhead exponentiell größer ausfallen würde als bei nVidia.

Ich wage mal zu behaupten, dass es keine genauen Information darüber gibt wie groß die Queue-Size beim CP bei den GCN-Generationen im Vergleich ausfällt und wie bei Nvidia.
Ebenso, welche Cache-Size hat denn mit dem Thema etwas zu tun?

Oxide hat damals noch die Batch-Sizes für GCN bei Mantle so optimiert, dass mehr auf der CPU gesammelt wurde, bevor es zur GPU abgeschickt wurde, da bei vielen und kleinen Batches der Command-Processor der GPU nicht mehr hinterherkam:

Update: Oxide Games has emailed us this evening with a bit more detail about what's going on under the hood, and why Mantle batch submission times are higher. When working with large numbers of very small batches, Star Swarm is capable of throwing enough work at the GPU such that the GPU's command processor becomes the bottleneck. For this reason the Mantle path includes an optimization routine for small batches (OptimizeSmallBatch=1), which trades GPU power for CPU power, doing a second pass on the batches in the CPU to combine some of them before submitting them to the GPU. This bypasses the command processor bottleneck, but it increases the amount of work the CPU needs to do (though note that in AMD's case, it's still several times faster than DX11).

https://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/6

Und da die GPUs nur die Command-Buffer interessieren, liegt es am Hersteller wie er davor die DX11-Maschinerie auf der CPU auflöst.
AMD hat die Kontrolle über die abgeschickten Größen und welche Teile vom Treiber sie über mehrere Threads auslagern könnten.
Ich sehe keine prinzipiellen Gründe, wieso bei AMD irgendetwas von der Umsetzung her nicht möglich wäre und die Kosten im Vergleich zu Nvidia explodieren würden.
Genauso sehe ich auf der anderen Seite keinen Grund, wieso man Nvidia angeblich mit dem DX12-Modell Probleme haben sollte.

 

[Luxmanl525]

Hallo zusammen,

@ Wadenbeisser

Zudem dürfte sich die Programmierung für DX12 erheblich von der von DX11 und Co. unterscheiden weil man sich ganz einfach um erheblich mehr Sachen selbst kümmern muss die einem zuvor die API abgenommen hatte.

Ganz genauso ist es. Auf Direct X 12 optimierte Spiele sind deutlich aufwendiger zu Programmieren. Das ist auch der Hauptgrund, weshalb sich da so wenig tut. Für die Firmen bedeutet es erheblich höhere Kosten, weshalb sie sich davor Scheuen.

Und vor allem, damit ein Spiel wirklich die Direct X 12 Vorteile zum Ausdruck bringen kann, muß dasselbe von Grund auf für Direct X 12 Programmiert sein. Deshalb gibt es auch nach wie vor noch so wenige Spiele mit Direct X 12, die wirklich etwas bringen.

So long...

 

[Wadenbeisser]

Ich sehe keine prinzipiellen Gründe, wieso bei AMD irgendetwas von der Umsetzung her nicht möglich wäre und die Kosten im Vergleich zu Nvidia explodieren würden.
Genauso sehe ich auf der anderen Seite keinen Grund, wieso man Nvidia angeblich mit dem DX12-Modell Probleme haben sollte.

Die brauchen im Vergleich zu nvidia auch nicht explodieren denn sie haben bereits ein kleineres Budget mit dem sie gegen nvidia UND Intel konkurrierne müssen.

 

[G3cko]

Dx11 und Dx12 sind so grundverschieden, dass es praktisch unmöglich ist Dx12 nachträglich sinnvoll zu implementieren. Das ist wieder ein super Beispiel dafür und zeigt eigentlich nur eins: Low Level bedeutet von Grund auf neu programmieren zu müssen und das ganze als einzige API. Ansonsten kann man sich wie bei allen Dx12 portierungen den Aufwand sparen.

Bis jetzt gibt es keine 5 spiele die eine gelungene Umsetzung zeigen konnten. Umso mehr muss man den Hut vor den AotS entwicklern ziehen. Aber hier stand auch Dx12 im Fokus und dx11 kam nachträglich.

 

[feidl74]

wenn schon inhaltlich sachen von vor 10 jahren aufgewärmt werden( z.b. jägerpets wieder nur eine spezialisierung, schlachruf krieger Stärkungsbuffs), dann pfuscht man halt an der Technik rum. absolut nerviges grafikmenü. im fesntermodus kann ich 2560x1440 benutzen, sobald ich aber auf fenstervollbild umstelle springt die Auflösung auf 3540x2160. die skalierungsfunktion ist eher auch sinnfrei da ich nicht auf 2560x1440 skalieren kann. dx11 läuft seit dem patch schlechter auf nvidia wie vorher. fps einbrüche in gebieten, die vorher perforannt liefen. warum so ein unterirdisches grafikmenü, bei der ich nur fensterbild Optionen auswählen kann. im vollbildmodus lief das wesentlich besser....

 

[Locuza]

Die brauchen im Vergleich zu nvidia auch nicht explodieren denn sie haben bereits ein kleineres Budget mit dem sie gegen nvidia UND Intel konkurrierne müssen.

Bezogen auf den Kontext ging es um performancetechnische Kosten, wo bei AMD angeblich dank der Hardware eine ähnliche Treiberarchitektur wie bei Nvidia unter DX11 nicht möglich wäre.

[...]
Bis jetzt gibt es keine 5 spiele die eine gelungene Umsetzung zeigen konnten. Umso mehr muss man den Hut vor den AotS entwicklern ziehen. Aber hier stand auch Dx12 im Fokus und dx11 kam nachträglich.

Engine und Spiele hatten zuerst einen fertigen DX11-Pfad, bis zusätzlich Mantle integriert wurde und bei AotS in der Pre-Beta die erste DX12-Umsetzung, die zum finalen Spiel noch einmal deutlich ausgefallener wurde.
Zum Schluss kam noch Vulkan dazu.

 

[Wadenbeisser]

@Locuza
So ist es doch auch, nvidia setzt bei ihren Karten in Hardware eine erhebliche Sparversion des Shedulers ein die auf zusätzliche Zuarbeiten durch die CPU angewiesen ist. Dadurch ist es ihnen zwar auch möglich die Unzulänglichkeiten von DX11 zumindest teilweise zu umgehen, dürfte aber auch den Aufwand bei der Treiberentwicklung deutlich erhöhen. Der höhere Aufwand dürfte letztendlich auch die Kosten bei der Treiberentwicklung erhöhen, Geld das bei AMD an anderen Stellen deutlich besser angelegt wäre.
Ich sehe es aber auch prinzipiell als sinnlos an Unzulänglichkeiten einer API, welche schon längst einen Nachfolger ohne diese Schwächen hat, rumzubasteln anstatt diese in die verdiente Rente zu schicken.

 

[Locuza]

@Wadenbeisser
So ist es eben nicht, weil das nicht stimmt.
Und zwar kostet gute Performance unter impliziten APIs viel Entwicklungsaufwand, aber die expliziten APIs verbreiten sich nicht rasend schnell, vor allem nicht mit guten Implementierungen, entsprechend hat der Konkurrent die Nase vorn bzw. muss man als Kunde mit schlechterer Performance auskommen.

 

[DriveByFM]

Also auf meinem Haupt-Rechner läuft es mit DX12 deutlich besser bzw. flüssiger als mit DX11. Aber auf dem 2ten Rechner genau andersrum, da ist DX11 besser.
Kann nur jedem empfehlen selber herum zu testen.

 

[Wadenbeisser]

@Locuza
So ist es eben doch, wer die alten APIs nutzen will der muss dann auch mit deren Beschränkungen klar kommen und nicht für ein Workaround programmieren.
DX11 ist nunmal ein multicore Krüppel der nicht in der Lage ist heutige CPUs effizient zu nutzen.
Entweder legt man das Spiels selbst darauf aus oder nutzt gleich eine API die das Problem nicht hat.

 

[Locuza]

@Wadenbeisser

Das die alten APIs konzeptionell ihre Limits haben ist klar, nicht aber das der Treiber es nicht deutlich besser machen könnte bei AMD, genauso wenig das Nvidia eine Sparversion eines Schedulers hätte und deswegen allgemein Probleme mit DX12 hat.

 

[donend]

Wenn man Blizzard hier richtig versteht:

The graphics options tied to each numerical preset have changed. Previously, all individual settings maxed out at level 8, with 9 and 10 adding extended distances. Now, those settings max out at 10. Assuming all else is equal and you're still on DX 11, the level 10 preset should offer the same performance as before, but the presets beneath it should offer better performance than they did before solely due to the attached graphics options being lower than they previously were at the same preset.

If you've become accustomed to playing on a certain graphical preset, you may want to experiment with raising it 1-2 levels after the servers go live. Otherwise, some of your settings have been reduced.

Dann unterstützen sie nicht nur kein wirkliches DX12 (Fallback bis FL10), sondern haben bezüglich des Borderlessmode auch die Qualität einige Levelstufen runtergefahren, die man nur mit Erhöhung des Offset um zwei Stufen wieder auf die altbewährte Quali unter DX9 erreicht.

Denke es ging nur darum, optionale Feature neuerer Hardware auszunutzen, wozu auch immer. FL9 Funktionalität bringt ein Port ohne wirkliche DX12 Unterstützung sowieso mit.

Aots profitiert ungemein von Drawcalls, vermutlich schmeckt das dem Hardwaresheduler von GCN, der ansonsten im CPU Limit deutlich schlechter aussieht als Nvidias Variante und viel Optimierungsarbeit beim Entwickler braucht.

Das WOWs Engine jetzt vollständig DX12 API kompatibel sein soll, kann man so jedenfalls kaum glauben.

 

[Locuza]

@donend

DX12 selber hat keinen Fallback-Modus und das niedrigste Feature-Level welches man unter DX12 verwenden kann ist FL11_0.
Und DX12 FL11_0 und DX11 FL11_0 sind unterschiedlich, zwar ist der definierte Funktionsumfang in großen Teilen gleich, aber viele grundlegende Bausteine und Funktionen unterscheiden sich nach wie vor.
Völlig unabhängig vom FL kann man bei DX12 immer die Command-Buffer über mehrere Threads füttern und "Async Compute und Async Copy" stehen einem auch immer zur Verfügung, genauso wie man sich immer explizit selber um die Speicherverwaltung kümmern muss und Resource-Transitions.

Bezüglich AotS muss man das Ganze umformulieren, AotS profitiert nicht von Drawcalls, sondern von günstigen Drawcalls.
AMD profitiert bei AotS unter DX12 in mehreren Bereichen, vom besseren Multithreading, vermutlich auch ebenbürtigen bis besserem Resource-Management und Async Compute, was AMD hilft ein paar Leerphasen zu füllen.

Die WoW Engine ist jetzt vollständig DX12 API kompatibel, sonst würde es nicht laufen, nur heißt laufen natürlich nicht das die Umsetzung auch gut ist und alle nützlichen Features von DX12 verwendet werden.

 

[donend]

Es wäre mal interessant zu wissen, ob WOW jetzt noch auf älteren Betriebssystemen startet, denn dann hat man bei Version 6.00.6000.16386 einfach einen Cut gemacht, anders kann man diese Andeutung von Level 10 irgendwas jedenfalls nicht deuten. Dann meint man klar DX10 und nicht 11, und dann würden BS älter als Vista rausfliegen und man spart sich die Optimierungsarbeit.

Mit 12 nutzt man dann tatsächlich lediglich die Multitaskfähigkeit unter Windows 10 aus und zwingt den Anwender/Gamer auf Windows 10 zu setzen. Daher wohl auch kein exklusiver Vollbildmodus mehr, sondern Borderless.

Es geht damit gar nicht darum irgendein neueres oder hardwarenahes Pixelshadermodell zu unterstützen, sondern man will ältere Betriebssystemversionen ausschließen, die keine Updates mehr erhalten, was dann den Entwicklern viel zusätzliche Arbeit machen würde.

 

[Locuza]

WoW unterstützt kein DX9 und 32-bit mehr, XP ist damit Geschichte.
DX11 bietet noch Feature-Levels bis hinab auf FL9_x, was vermutlich kaum eine Anwendung verwendet.
Aber Entwickler haben DX11 häufiger verwendet, um mit FL10_0 DX10 Hardware zu unterstützen, so auch WoW.

 

[donend]

Ich vermute man hat DX9 einfach zu UWP portiert und das kann kein DX12 sein. Die Performanceslides sind zu unterschiedlich und man kann Ports so lediglich in einem App Fenster ausführen. Der Code dafür ist Bestandteil des Grafikframeworks das Microsoft dazu anbietet.

Vulkan fällt damit raus, weil es sich eben nicht um LowLewel handelt. Die Runtimeversionen mit ihren Leveln sind mittlerweile so schwammig...weil man eben Entwicklern die Chance geben wollte damit zurechtzukommen und nicht gleich jegliche Hardware in die Wüste verdammt.

Der Vega Perfomancevorteil liegt dann tatsächlich nur beim Windows 10 Threadsheduling wobei AMD Multitask dann schmecken dürfte, das hat mit AMD DX12 Power und Steigerungen kaum was zu tun. Wäre ja mal schön wenn das jemand unter Windows 7 testet, denn dann könnte sich das Blatt vollständig wenden. AMD hat ja schon seit Ewigkeiten Probleme den Hardwaresheduler auch auszulasten und im CPU Limit siehst dann auch treibertechnisch übel aus.

 

[BOBderBAGGER]

WoW unterstützt kein DX9 und 32-bit mehr, XP ist damit Geschichte.

Offiziell ist XP schon seit Oktober letzten Jahres Geschichte.

 

[Locuza]

@donend

WoW ist keine UWP-App geworden und UWP-Apps können nativ nur mit DX11 oder DX12 erstellt werden.

 

[Wadenbeisser]

@Locuza
Es ging aber nicht darum ob es möglich wäre, für deren Einschätzung uns das nötige technische Verständnis fehlt, sondern darum ob sie sich solche extravaganzen (es gibt schließlich bereits mehrere Alternativen ohne dieses Problem) leisten können. Angesichts deren Position am Markt wohl kaum denn die dafür nötigen Mittel müssten an anderen Stellen abgezogen werden. Wer an veralteter Technik festhalten will bitte, dann kann er sich an die Marktführer halten.