NVIDIA GeForce GTX 980 und 970 mit Maxwell-Architektur im XXL-Test - DirectX 12 und Maxwell

Maxwell ist die erste Architektur von NVIDIA mit DirectX-12-Unterstützung. Noch hat Microsoft die finalen Voraussetzungen für DirectX 12 nicht festgelegt, doch NVIDIA will zumindest bereits einen Teil der notwendigen Spezifikationen umgesetzt haben. Ob dies letztendlich auch bedeutet, dass man die kompletten Features auf Hardwareebene unterstützen wird, ließ man allerdings noch offen.

Dass man für DirectX 12 bereit ist, zeigte man mit einer kurzen Demo der Unreal Engine auf Basis von DirectX 12. Für Entwickler mit Developer-Zugang zur Unreal Engine sowie dem Developer Kit bei Microsoft kann bereits heute mit den Arbeiten an einem DirectX-12-Spiel begonnen werden. Ein Vertreter von Microsoft bestätigte noch einmal die aktuelle Roadmap für DirectX 12, das ab Herbst/Winter 2015 verfügbar sein soll. Dies gilt auch für die Implementation von DirectX 11.3, welches den Software-Subset von DirectX 12 auch auf die DirectX-11-Ebene bringen soll. Mit wie vielen Spielen dann zu rechnen ist, ließ man dabei aber offen.

Das DirectX 12 für Entwickler bereits ein Thema ist, wollte man mit einer Demo von Fable unter Beweis stellen:

Wie gesagt, noch sind die finalen Feature-Sets für DirectX 12 nicht festgelegt und so konzentrierte man sich bei der Präsentation auf das, was bereits spezifiziert ist. Zu den neuen Render-Features gehören unter anderem Rasterizer Ordered Views. Diese spielen bei zahlreichen Render- und Filter-Techniken eine wichtige Rolle. Dazu gehören auch Anti-Aliasing und die Order Independent Transparency, auf die wir nun etwas genauer eingehen werden.

Order Independent Transparency beschreibt eine Problematik, die im Renderpfad auftaucht und bisher ungelöst blieb. Für transparente Objekte war dabei nicht immer klar, in welcher Reihenfolge sie dargestellt werden sollen. Entwickler hatten nur die Wahl viel Rechenaufwand auf das Problem zu werfen, was zu einer korrekten Berechnung führte, aber recht langsam war. Wurde weniger Rechenaufwand investiert, konnte es zu fehlerhaften Darstellungen kommen und Objekte, die eigentlich hinter einem transparenten Objekt liegen sollten, werden davor dargestellt. Rasterizer Ordered Views machen eine korrekte Berechnung möglich, ohne dass dabei zu viel Rechenleistung aufgewendet werden muss.

In einem Beispiel wird die Berechnung eines bestimmten Objekts abhängig vom Viewport, also der sichtbaren Darstellung gezeigt. Problematisch war bisher, dass die rote Fläche durch das transparente Objekt "hindurchberechnet" werden muss. Typischerweise kam der Algorithmus aber immer zu unterschiedlichen Ergebnissen, sodass ein Objekt meist falsch hinter bzw. vor einem transparenten Objekt dargestellt wurde. Mit Hilfe der Rasterizer Ordered Views stimmen die Berechnungen bei jedem Durchlauf.

DirectX 12 hebt auch einige Beschränkungen auf, die wir aus dem Wechsel der CPU-Architektur und Betriebssystem von 32 auf 64 Bit her kennen. So können manche Variablen nur eine Länge von 32 Bit mitbringen und kollidieren an anderer Stelle mit falschen Dateiwerten und Typen.

Maxwell und DirectX 12

Ein weiterer wichtiger Punkt für DirectX 12 sind Tiled Resources, die sowohl für eine hohe Effizienz bei der Nutzung des Speichers sorgen, als auch deren Detailgrad verbessern sollen und die sogenannten Mega-Texturen möglich machen. Durch die Nutzung einer kleineren Textur in mehreren Ausrichtungen können größere Texturen simuliert werden. Eingespart wird natürlich der Speicherbedarf. Darunter nicht leiden soll allerdings die Darstellungsqualität.

In einem Beispiel wird eine klassische Texture 3D in DirectX 11 mit 1.200 x 600 x 600 Pixel genannt, die bei 32 Bit Farbtiefe auf eine Größe von 1,6 GB kommt. Bei gleicher Texturqualität kommt eine Tiled Texture 3D auf 32 x 32 x 16 Pixel mit 32 Bit Farbtiefe auf 156 MB und wird einfach mehrfach verwendet. In einem Beispiel war eine Renderszene zu sehen, in der dieses Tiled Volume 2.500 mal verwendet werden konnte.

Dritter Punkt bei der Unterstützung von DirectX 12 ist die Conservative Rasterization. Sie kommt z.B. beim Filter von Dynamic Super Resolution und auch beim Multiframe Sampled Anti-Aliasing zum Einsatz.

Maxwell und DirectX 12

Beim Rasterizing eines kleinen Objekts/Pixels werden diese durch eine bessere Positionierung der Sample-Punkte besser bzw. überhaupt erst abgedeckt und damit erkannt. Ebenfalls eine Rolle spielt die Conservative Rasterization bei der Voxelization von VXGI. Auch die Conservative Rasterization setzt zu einem gewissen Grad bestimmte Hardware voraus, so dass sie nur auf den neuen GPUs ausgeführt werden kann.

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 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 - 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.

Mit einem neuen Bind Model trägt Microsoft in DirectX 12 der größeren Anzahl an CPU-Kernen sowie der größeren Performance bzw. breiteren Parallelisierung Rechnung. Zudem reduziert man an dieser Stelle den CPU-Overhead. Eine Rolle spielt dies auch bei den Command Lists. 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 dass sie noch einmal zusammengestellt werden muss. Alle Instruktionen und Befehle müssen also nur einmal erstellt werden.

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.

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.

Im obigen 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.

Insgesamt ist das Bild von DirectX 12 und den gebotenen Features noch recht diffus. Es ist schwer einen Überblick über die Software- und Hardware-Features zu behalten und somit ist auch noch nicht ganz klar, welche der oben genannten Features eine bestimmte Hardware voraussetzen und welche nicht. Für einige Beispiele haben wir die Hardwarevoraussetzungen genannt, für andere bleiben sie zunächst im Dunkeln. Es wird also dabei bleiben, dass bei der Unterstützung von DirectX 12 und 11.3 unterschieden werden muss, ob von Software- oder von Hardware-Features die Rede ist.