AMD und Nvidia zu DirectX 12: "Top-Titel sehen generell besser aus"
20 Jahre nach DirectX 1 erscheint in diesem Jahr DirectX 12. Microsofts neueste Programmierschnittstelle soll anspruchsvolle 3D-Grafikberechung und -ausgabe gewaltig verbessern. Auf der Game Developers Conference waren erste Spiele mit der neuen Schnittstelle zu sehen.
Bereits im letzten Jahr war DirectX 12 eins der großen Themen der Game Developers Conference. Auch in diesem Jahr fanden etliche Sessions zu der neuen Grafikschnittstelle statt. Allerdings ging es dort weniger um sensationelle Neuerungen. Vielmehr stellten zahlreiche Programmierer erste Ergebnisse mit DX12-Spielen vor. Das ging meist extrem in die Tiefe. Am Ende eines Vortrags meinte ein Redner sinngemäß: "Wer hier alle Folien verstanden hat, soll sich bitte bei mir melden, ich habe eine Stelle für ihn."
DirectX 12: Was bisher geschah
In einem gemeinsamen Vortrag von AMD und Nvidia gaben Mitarbeiter beider Firmen ein Update über die derzeitigen DX12-Implementierungen. David Oldcorn, Software Development Engineer bei AMD, gab außerdem zu Protokoll, dass "etliche Konsolen-Paradigmen" den Weg in die Programmierschnittstelle gefunden hätten. "Wer Erfahrung mit der Programmierung für Spielkonsolen hat, hat einen Wissensvorsprung", so Oldcorn. Mit verbessertem Multithreading, Pipeline State Objects, Befehlslisten, Bundles und schlaueres Ressourcenmanagement soll DirectX12 wie bei Spielkonsolen eine hardwarenähere Programmierung mit mehr Kontrolle und weniger Speicherverschwendung ermöglichen. Das soll auch die Portierung von einem auf das andere System erleichtern.
Parallel rechnet sich's besser
Weil DirectX 12 effizienter als der Vorgänger arbeitet, sollen Mobilanwendungen batterieschonender sein, in Echtzeitstrategiespielen beziehungsweise MOBAs mehr Einheiten und Effekte auf dem Bildschirm erscheinen und Top-Titel generell besser aussehen. Denn in einen besser verwalteten Grafikspeicher passen mehr Details. Dazu müssen, so David Oldcorn, Programmierer darauf achten, Befehle zu parallelisieren und mit Hilfe von Bundles oft genutzte Befehle schneller aufzurufen. "Dabei ist es wichtig, ähnliche Prozesse in separaten Threads unterzubringen", sagt Oldcorn. "Passt auf, was ihr dem Treiber wann übergebt. Befehle sollten nach der Häufigkeit ihrer Aufrufe gruppiert werden."
Schnellere Engine und mehr Bilder
Verglichen mit DirectX 11 soll DirectX 12 seine Stärken am prägnantesten in neu entwickelten Grafik-Engines ausspielen. "Wer nur eine bestehende Engine portiert, wird vom gewaltigen Leistungspotenzial von DirectX 12 nicht viel sehen", warnt David Oldcorn. Neue Engines sollen hingegen "eine Größenordnung schneller" sein. Zwei Beispiele demonstrieren das anschaulich. Die Nitrous-Engine des Strategiespiels "Ashes of the Singularity" (Stardock) braucht in der DX12-Fassung gut zwei Millisekunden mit Treiberberechnungen, während die DX11-Version etwa 25 Millisekunden dafür benötigt. Zeit, die das Spiel für die Darstellung von mehr Einheiten oder den Einsatz besserer KI nutzen könnte. Bei dem mit der Unreal Engine entwickelten "Fable Legends" (Microsoft) bringt die DirectX-12-Version aus diesem Grund rund zehn Prozent mehr Bilder pro Sekunde auf den Schirm. Zur E3 sehen wir hoffentlich einige weitere Titel, die dann im Herbst und Winter dieses Jahres auf Windows 10 den Nachbrenner zünden werden.
DirectX 12 - Looking back at GDC 2015 and a year of amazing progress - DirectX Developer Blog - Site Home - MSDN Blogs
Folgende "Features" gibt es für eine bessere GPU-Performance:
Explicit resource transitions:
Das war die Sache mit den UAV-Barriers.
UAV = Unordered Access Views.
Grob gesagt, unter DX11 mussten Pausen eingefügt werden, damit State-Wechsel/Zugriffe auf die Ressourcen immer in einer festen Reihenfolge ausgeführt werden.
Das DX12 Modell sieht vor, dass der Entwickler es hier selber definiert.
Dadurch muss der Treiber nicht zwangsweise Dinge garantieren, sondern die App selber.
Richtig ausgeführt führt es dazu, dass man sich viele eingefügten Zwangspausen sparen kann, wenn man dem Treiber einfach garantiert das während der Zeit nicht auf die Ressourcen zugegriffen wird.
Die Sache hat bei dem Fable-Legends Beispiel 20% gebracht.
Multi-Engine:
Die ALUs von GPUs führen Arbeiten durch, die in eine Arbeitsschlange gepackt werden, in Queues.
Der Command-Processor ist dafür zuständig, dass die Arbeiten an die ALUs verteilt werden.
Damals gab es praktisch nur 3D-Queues, mit modernen APIs gibt es auch Compute-Queues.
Das Problem an dieser Stelle ist, dass man nicht parallel mehrere Queues verschicken konnte, eben bis jetzt mit DX12. (Und andere moderne APIs)
Bei alten APIs müssen Compute und 3D Aufgaben in eine Queue gepackt werden, da gibt es Abhängigkeiten, es geschieht alles in einer gewissen Reihenfolge.
Viel cooler wäre es natürlich wenn man Compute und 3D unabhängig an die ALUs verschicken könnte und das ganze asynchron berechnet wird.
Um so etwas zu ermöglichen hat AMD z.B. ACEs (asynchronous compute engines) in ihre Hardware verbaut.
Dadurch kann AMD neben 3D Queues, parallel auch Compute-Queues verschicken.
Neben 3D und Compute kann die GPU natürlich auch andere Aufgaben erledigen, z.B. Speicherzugriffe.
Mit DMA-Engines (Direct Memory Access) kannst auch noch das ganze parallel gestalten.
An dieser Stelle habe ich das Beispiel mit dem PS4 exklusivem Spiel gebracht, welches ihr Lightning durch Compute berechnet und dank async compute rund 20% Performance gewonnen hat.
Das ganze muss aber natürlich designen.
AMD steht da gut da, Intel hat keine Hardware die mehrere Queues gleichzeitig abschicken kann.
Intels bisheriger Hardware bringt es also gar nichts, ob man mehrere Queues hat oder alle Aufgaben in eine Queue packt, muss so oder nacheinander verteilt werden.
Intel hat aber eine DMA-Engine, sie geben allerdings einschränkend zu, dass diese langsam ist.
Nvidia hat Hyper-Q, grob das gleiche wie AMDs ACEs, bloß gab es dieses Feature nur beim GK110 und man gibt zwar an, dass jede Maxwell GPU es auch hat, aber da fehlen Infos, welche Beschränkungen es gibt.
Wie viele Queues können verteilt werden etc.
ExecuteIndirect:
Soweit ich es verstanden habe, kann man mit einem API-Befehl dadurch mehrere Draw-Calls auf einmal ausführen lassen.
Normalerweise muss die CPU jedes mal der GPU sagen, was sie als nächstes tun soll.
Mit ExecuteIndirect bekommt man die Möglichkeit, welche wieder nur zur Verfügung steht wenn man gewisse Dinge passend anordnet, durch einen Befehl der GPU praktisch eine Liste zu ergeben.
Die GPU kann dann für eine gewisse Sachen unabhängig von der CPU weiter Sachen ausführen.
Das entlastet stark die CPU, hilft aber auch der GPU ~10% beim Asteroiden Beispiel. (Intel Hardware)
Dann gab es noch die Sache mit Bindless.
Bei alter Hardware wurden Ressourcen immer fest angebunden, wolltest du mehr Ressourcen nutzen musstest du alte erst entbinden etc.
GCN arbeitet intern z.B. immer bindless, es gibt keine binding-slots, allerdings arbeitet DX11 immer noch so, als müssten Ressourcen gebunden werden.
Intels Hardware konnte dadurch rund 10% gewinnen.
Das war ungefähr grob das, was ich verstanden habe.
DX12 zielt aber hauptsächlich auf die CPU Performance ab. Die hat im GPU limit eben nur wenig bis gar keine Auswirkungen.
Positiv ist halt, dass wir unsere CPUs in Zukunft wahrscheinlich deutlich seltener aufrüsten müssen, da sind dann wirklich Performance Gewinne von 50-100% Möglich, je nach Spiel eben. Wie viele Jahre eine CPU in Zukunft ausreicht, wenn sagen wir mal BF4 statt 80% CPU Last nur noch 40% Last erzeugt kannst du dir ja dann gut vorstellen.
Direkt an den FPS wird sich DX12 nur bemerkbar machen, wenn das Spiel unter DX11 CPU limitiert war.
Natürlich könnten die Entwickler die freigewordene CPU performance auch nutzen, um mehr Objekte und höhere Weitsicht zu ermöglichen. Wodurch sich der Vorteil der Kostenersparnis wieder relativiert. Man muss aber auch bedenken, dass die Konsolen CPU Seitig nicht so gut bestück sind. Sprich das Spieldesign wird sich die nächsten Jahre überwiegend an den Möglichkeiten der Konsolen CPU orientieren und wir freuen uns, dass in den meisten Games bald mit etwas Glück sogar ein i3 für 60+ FPS ausreichend ist....
Aber ja, für mich wäre einfacher, einfach einfacher.
Ich lese immer gerne mit, bin auch wissbegierig, aber du hast gerade den Vogel abgeschossen. Jetzt komme ich mir richtig dumm vor
Durch Bindless Ressources und ExecuteIndirect konnte z.B. in einer vorgeführten Asteroiden Demo von Intel, jeweils 10% gewonnen werden.
Das eingebettete Video von Fable Legends in diesem Artikel gewinnt 20% im GPU-Limit durch UAV Barriers.
Zusätzlich bietet DX12 das Modell Multi-Engine, womit man insgesamt 3 unabhängige Datenströme generieren kann, im Gegensatz zu einem Datenstrom unter DX11.
Graphics, Compute und Copy.
AMDs GCN GPUs haben dank den ACEs mehrere Compute-Queues die sie verteilen können und ein paar DMA-Engines für Copy-Vorgänge.
Das kann richtig programmiert und angepasst ordentlich viel Leistung im GPU-Limit bei Radeon-GPUs bringen.
Z.B. das PS4 exklusive Spiel The Tomorrow Children kann durch async compute bis zu 20% an Leistung im GPU-Limit erreichen.
...
... ... ...
Hoppla, darf ich das überhaupt zugeben?