Werbung
Vor kurzem erläuterte Microsoft erstmals seine Pläne bezüglich DirectX 12 und sorgte gleich für einige Überraschungen. So konzentriert man sich bei Microsoft nicht auf die Entwicklung neuer Features und Effekte, sondern will vor allem an der Effektivität von DirectX arbeiten. Letztendlich soll die effektivere Nutzung von Hard- und Software aber dazu führen, dass die Grafikqualität der Engines noch weiter zunimmt, sodass wiederum schon von einer neuer Detailstufe gesprochen werden kann. Außerdem soll die meiste bereits ausgelieferte Hardware in Form von Prozessoren und IGPs in der Lage sein per DirectX 12 zu kommunizieren. Ob nun ausschließlich Windows 8, Windows 8.1, Windows Phone "Blue" und die Xbox One in der Lage sein werden DirectX 12 einzusetzen, ließ Microsoft vorerst noch einmal offen - klar ist allerdings, dass man die Kompatibilität möglichst breit anlegen möchte.
[figure image=images/stories/newsbilder/aschilling/2014/directx12-teaser600px.jpg]DirectX 12[/figure]
Zunächst einmal etwas Hintergrund zur Entwicklung von DirectX 12. Gerne werden zeitliche Zusammenhänge zwischen der Mantle-API von AMD und DirectX 12 von Microsoft genannt - manche sehen DirectX 12 sogar als Reaktion auf Mantle. Doch dazu muss man wissen, dass eine solche API nicht innerhalb von wenigen Wochen oder Monaten entwickelt werden kann. Laut AMD arbeitete man fünf Jahren mit Entwicklern aus verschiedenen Spiele-Studios zusammen, bevor man Ende letzten Jahres das erste mal damit an die Öffentlichkeit ging. Laut AMD und NVIDIA dauert die Zusammenarbeit zu DirectX 12 mehr als vier Jahre an. Direkte Zusammenhänge zwischen den APIs sind also auszuschließen, wenngleich es natürlich zu Überschneidungen der Interessensbereiche kommt und es nicht auszuschließen ist, dass hier ein gewisser Informationsaustausch innerhalb der Unternehmen stattgefunden hat. Professionelle Unternehmen versuchen diese Konflikte aber weitestgehend zu vermeiden, um nicht in eine Schieflage innerhalb der Partnerschaft zu geraten.
[h3]Multi-Thread-Skalierung[/h3]
Ob zwei, vier, sechs oder gar acht Kerne, zuzüglich Hyper-Threading kommen schnell bis zu einem Dutzend Kerne zusammen, die aktuell von der Software beansprucht werden können. Richtig effektiv genutzt werden aber nur die wenigsten davon. Gute Engines schaffen es halbwegs vernünftig fünf bis sechs Kerne zu nutzen, von einer effektiven Nutzung ist aber selbst dann noch nicht zu sprechen.
Um dies zu demonstrieren hat Microsoft jeweils eine DirectX-11- und eine DirectX-12-Version des 3DMark von Futuremark genommen und einmal die Auslastung der CPU-Kerne aufgeführt. Während im oberen Fall die Aufgaben zwar auf vier Threads aufgeteilt sind, ist die CPU-Time dennoch extrem hoch, da der Thread0 einige seiner Tasks nicht auf die weiteren freien Threads auslagern kann.
[figure image=images/stories/newsbilder/aschilling/2014/directx12-comp-1-rs.jpg link=images/stories/newsbilder/aschilling/2014/directx12-comp-1.jpg alt=Visualisierung der besser Ausnutzung der CPU]Visualisierung der besser Ausnutzung der CPU[/figure]
Im unteren Beispiel unter DirectX 12 sind gleich zwei Effekte zu erkennen: Zum einen sind die Aufgaben besser auf die vier Threads verteilt (beispielsweise der Tasks des "UM Driver"), zum zweiten reduziert DirectX 12 den Overhead, also die unnötigen Berechnungen, was die einzelnen Aufgaben auch in kürzerer Zeit bearbeiten lässt. Diese kürzeren CPU-Zeiten bzw. Latenzen sorgen in der Folge dafür, dass die GPU nicht mehr auf die CPU warten muss, was in letzter Konsequenz für mehr FPS sorgt.
Ebenfalls angepasst wurde Forza Motorsport 5, dass dazu extra von der Xbox-One-Version auf DirectX 12 portiert wurde. Genutzt wurde zur Darstellung der Performance eine GeForce GTX Titan Black Edition, da man zeigen wollte, dass selbst bei hohen Qualitätseinstellungen die Möglichkeit vorhanden ist konstante 60 FPS zu halten, was gerade im Hinblick auf den Einsatz mit einer VR-Brille oder der grundsätzlichen Diskussion zu möglichst stabilen FPS eine entscheidende Rolle spielt. Auf die zuvor notwenige Vorhaltung eines Double- oder Triple-Buffers gehen wir später noch etwas genauer ein.
[figure image=images/stories/newsbilder/aschilling/2014/directx12-comp-2-rs.jpg link=images/stories/newsbilder/aschilling/2014/directx12-comp-2.jpg alt=CPU-Time-Vergleich zwischen DirectX 11 und DirectX 12]CPU-Time-Vergleich zwischen DirectX 11 und DirectX 12[/figure]
Eine weitere Demo betrifft die Cryengine, die natürlich ebenfalls DirectX 12 unterstützen wird. Auch hier demonstrierte Microsoft die niedrigen CPU-Latenzen, was wiederum zu mehr FPS führen soll.
[h3]Pipeline States[/h3]
Noch in DirectX 11 erlaubt Microsoft die Manipulation von zahlreichen sogenanntes States, um ein orthogonales Objekt zu umschreiben. Die dabei verwendeten Input Assembler States, Pixel Shader States, Rasterizer States und Output Merger States konnten unabhängig voneinander modifiziert werden. Zwar sorgte dies für eine gute Flexibilität innerhalb der Programmierung einer der Grafik-Pipeline, passte aber nicht sonderlich gut zur Art und Weise wie moderne GPUs arbeiten. So fassen die Hardware-Hersteller gerne Pixel Shader State und Output Merger State in eine dediziertes Stück Hardware zusammen, aufgrund der Unabhängigkeit dieser Komponenten in DirectX 11 konnte es aber dazu kommen, dass der Treiber den kompletten State aus allen Teilbereichen nicht zusammenfassen konnte und somit kam es zu einer verzögerten Draw Time (Darstellung des eigentlichen Frames). Diese überflüssigen Wartezeiten sorgten letztendlich also dafür, dass weniger Draw Calls pro Frame durch die Pipelines geschickt werden konnten.
DirectX 12 fasst diese unterschiedlichen States nun zu einem Pipeline State Object (PSO) zusammen. Soft- und Hardware sprechen nun also bereits in kompletten Blöcken, die so auch viel schneller in der Hardware berechnet werden können. Diese PSOs können auch dynamisch geändert werden und müssen nicht jedes mal im kompletten Umfang berechnet werden. Aus all diesen Maßnahmen resultieren deutlich mehr Draw Calls pro Frame für deutlich mehr Objekte in einem Frame bzw. in höheren FPS.
[h3]Work Submissions[/h3]
In DirectX 11 waren die sogenannten Command Lists eine unendliche Aneinanderreihung von Befehlen für die GPU. Dies entspricht allerdings wiederum nicht der Art und Weise wie Hardware gleich mehrere Aufgaben gleichzeitig erledigen kann, denn da diese Command List seriell abgearbeitet werden muss, muss ein Schedular dafür sorgen, dass diese Aufteilung möglichst effizient geschieht, was nicht immer ideal gelingt.
DirectX 12 schickt nun nicht mehr eine lineare Liste über den Treiber an die GPU, sondern bereits vordefinierte und abgeschlossene Listen, die einen bestimmten Umfang an Aufgaben beinhalten, die dann von der GPU abgefertigt werden können und auf die Leistung und Möglichkeiten der Hardware zugeschnitten ist. Während diese Liste nun von der GPU abgearbeitet wird, stellt der Treiber in Abhängigkeit der jeweiligen Auslastung der vorangegangenen Liste eine weitere zusammen, die idealerweise bereits fertiggestellt ist, wenn die erste Liste abgearbeitet wurde. Letztendlich muss nur noch ein einziger serieller Prozess diese vordefinierten Listen wieder zusammenführen, was allerdings deutlich effizienter ist, als eine einzige serielle Liste mit allen Befehlen einzeln zu erstellen.
Die sogenannten Bundles sind eine Weiterentwicklung dieser vordefinierten Command Lists. Sollen z.B. zwei identische Objekte in einem Frame berechnet werden, die sich nur durch die Texturen unterscheiden, so wird im ersten Durchlauf die bereits vordefinierte Command List aufgezeichnet und danach einfach erneut ausgeführt, ohne das sie noch einmal zusammengestellt werden muss. Alle Instruktionen und Befehle müssen also nur einmal erstellt werden.
[h3]Resource Access[/h3]
Mit DirectX 12 möchte Microsoft den Entwicklern einen weitreichenderen Zugriff auf einige Ressourcen, beispielsweise den Speicher geben. In DirectX 11 wurden zunächst einmal sogenannte View Objects erstellt, die fest an bestimmte Slots gebunden wurden, welche wiederum fest mit einem Shader State in der Pipeline verknüpft waren. Die Shader konnten dann auf diese Slots zugreifen und die darin enthaltenen Daten lesen. Sollten aber bestimmte Daten mehrfach genutzt werden, mussten diese View Objects aber immer wieder neuen Slots und Shader States zugeschrieben werden. Auch hier liegt laut Microsoft einer der Gründe für den großen Overhead bei den Draw Calls.
Mit DirectX 12 können die Spieleentwickler vordefinierte Ressourcen festlegen, die in einem sogenannten Descriptor Heaps gespeichert sind. Es ist also von vorneherein festgelegt, welche Ressource durch welche Pipeline für einen bestimmten Draw Call genutzt wird. Natürlich können auch mehrere dieser Descriptor Heaps in kompletten Tabellen erstellt werden, sodass sich die Aufteilung der zur Verfügung stehenden Hardware anpassen lässt.
Viele moderne Engines nutzten das sogenannte Deferred Rendering. Dazu müssen sie sich einen G-Buffer anlegen, in dem die Resourcen für die Shader-Berechnungen festgelegt wurden. Dieser G-Buffer kann aber sehr schnell sehr voll werden, was Zugriffe darauf sehr langsam werden lässt. Daher hat Microsoft in DirectX 12 die Einteilung der Ressourcen sehr dynamisch gestaltet, was einen Wechsel bzw. eine neue Zuteilung schnell und einfach möglich machen soll.
Soweit zunächst einmal die ersten Erklärungen seitens NVIDIA. In der kommenden Woche werden wir uns auf der GTC 2014 von NVIDIA befinden und dort sicher noch deutlich mehr über DirectX 12 hören. Zunächst einmal bleibt also nur abzuwarten, ob Microsoft auch halten kann, was es verspricht. Noch in diesem Jahr soll eine erste Preview Version erscheinen, die dann auch einen Rückschluss auf das erreichte Performance-Plus zulässt.