Ashes of the Singularity mit DirectX 12 und Asynchronous Shaders im Benchmark-Vergleich

DirectX 12 dürfte in diesem Jahr mehr als nur eine Software-Theorie bleiben. Mit Ashes of the Singularity erscheint am 22. März ein erstes Spiel, welches mit der vollständigen Unterstützung von DirectX 12 daher kommt. Hitman ist ein zweiter Kandidat und zur GDC Mitte März werden noch weitere Ankündigungen erwartet. Heute schauen wir uns aber erst einmal die aktuelle Beta von Ashes of the Singularity an und vergleichen den Stand der Implementierungen zwischen AMD und NVIDIA, werfen aber auch einen Blick auf spezielle Funktionen wie die Asynchronous Shaders sowie verschiedene Multi-GPU-Implementierungen.

Seit mehr als zwei Jahren beschäftigen wir uns immer wieder ausgiebig mit dem Thema DirectX 12. Zu Anfang waren Microsoft und die weiteren beteiligten Unternehmen aber noch nicht sonderlich auskunftsfreudig und so sollte es bis September 2014 dauern, bis Microsoft und NVIDIA auf dem Launch-Event zur Maxwell-Architektur in Form der GeForce GTX 980 und 970 erste Details preisgaben. Darauf folgten immer wieder einige Updates und es war abzusehen, dass DirectX 12 auch bei AMD vor der Mantle-API den Vorzug bekommen wird. AMD konnte sich aber zu diesem Zeitpunkt bereits auf die Fahnen schreiben, eine Diskussion angestoßen zu haben, die letztendlich zu einer Umsetzung führt, von der alle profitieren sollen.

{jphoto image=92646}

Die Einführung zahlreicher Grafik-APIs in den vergangenen Jahren hat gezeigt, dass gerade bei der Softwareschnittstelle zwischen Hard- und Software noch einiges Potenzial vorhanden ist. AMD macht mit Mantle den Anfang, DirectX 12 ist mit Windows 10 eingeführt worden, bei OpenGL ist erst kürzlich die Version 1.0 der Vulkan-API veröffentlicht worden und Apple brachte den Denkanstoß mit Metal in den mobilen Bereich. Bisher war bei diesen Optimierungen meist nur von den sogenannten Draw Calls die Rede, deren Overhead in den Berechnungen des Prozessors reduziert wurde. Der API Overhead Test als neuer Feature-Test des Futuremark 3DMark zeigte an dieser Hinsicht wieder das Potenzial auf.

[h3]Die Asynchronous Shaders[/h3]

Es bedarf also nicht immer neuer Hardware, um deutlich mehr Leistung aus bestehenden Produkten zu kitzeln - so die Botschaft hinter den Erwartungen an DirectX 12. AMD spricht nun erstmals über ein Feature, welches sich eigentlich schon seit Einführung der "Graphics Core Next"-Architektur in den aktuellen GPUs befindet. Die sogenannten Asynchronous Shader sollen die Art und Weise, wie Engine, Treiber und Hardware miteinander sprechen und die Aufgaben verteilen, verbessern. Mit dem Launch der ersten Grafikkarten auf Basis der "Hawaii"-GPU sprach AMD aber noch von Verbesserungen beim GPU-Computing für die asynchrone Compute Engines. Jede GPU mit GCN-Architektur verfügt aber über diese speziellen Hardware-Einheiten. Was damals noch als ein reines Compute-Feature angesehen wurde, soll nun DirectX 12 bei Spielen auf die Sprünge helfen.

Bei den Betrachtungen einer GPU-Architektur erwähnen wir auch immer die einzelnen Funktionsblöcke, deren Funktionsweise und Verwendungszweck. Dabei zeigt sich, dass viele dieser Funktionseinheiten unabhängig voneinander arbeiten können, aufgrund des Rendering-Prozesses aber nicht in der Lage sind, so zu arbeiten, sondern meist linear nur eine sogenannte Queue abgearbeitet wird. Dieses schrittweise Abarbeiten versuchen die in allen Architekturen vorhandenen Scheduler zu optimieren, in dem sie die Aufgaben möglichst gleichmäßig verteilen, dies gelingt allerdings nur bis zu einem gewissen Grad.

Mit DirectX 12 verändert sich die Art und Weise der Zugriffe auf die API durch die Programmierer. Sie haben viel mehr Einfluss auf die Arbeitsschritte, sodass sich bestimmte Arbeitsprozesse besser organisieren lassen. Eine bessere Multi-Thread-Skalierung, Pipelines States und Work Submissions sind dabei die drei wichtigsten Werkzeuge, um den Rendering-Prozess entsprechend zu optimieren. In einer recht frühen Vorstellung von DirectX 12 durch Microsoft sind wir bereits darauf eingegangen.

Obiges Bild stellt die Abarbeitung der verschiedenen Rendering-Prozesse in DirectX 12 dar, während im Bild darüber die Arbeitsweise von DirectX 11 zu sehen ist. Die verkürzte Renderzeit äußert sich natürlich in höheren Frames pro Sekunde und reduziert auch die Latenzen, was in einigen Bereichen wie den VR-Brillen ebenfalls einen positiven Aspekt darstellt.

Nun können Entwickler die Aufgaben nicht beliebig verteilen, sondern müssen sich an gewisse Vorgaben der APIs halten. Moderne Spiele-Engines erlauben dazu eine Aufteilung in vordefinierte Queues, die unabhängig voneinander abgearbeitet werden können. In diesem Beispiel werden die Aufgaben in eine Grafik-, Compute- und Copy-Queue verteilt. Die API, hier DirectX 12, verteilt die Queues auf die zur Verfügung stehenden Ressourcen der GPU.

Was im Ansatz einfach klingt, ist in der Praxis aber weitaus komplizierter, denn auch diese verteilten Queues müssen auf die freien Ressourcen der GPU umgelegt werden. AMD erklärt einen Rendering-Prozess anhand eines Beispiels aus dem Autoverkehr. Die Kreuzung und Zusammenführung zweier Fahrspuren auf eine Spur mithilfe einer Ampel entspricht dabei der zu bewältigenden Aufgabe. Die Ampel ist dabei der Scheduler, der entscheiden muss, wann welcher Prozess in die Rendering-Pipeline eingeführt wird. Alle Schritte besitzen dabei die gleiche Priorität. Das Warten auf freie Ressourcen sowie das Umschalten benötigen also Zeit, die nicht sinnvoll genutzt wird.

Eine Möglichkeit diesen Prozess zu verbessern, sind die Pre-Emptions. Dabei werden einige Aufgaben priorisiert. Wieder am Beispiel des Autoverkehrs wird die blaue Queue angehalten, der höher priorisierte Prozess (lila) kann dann in den Rendering Prozess eingefügt werden. Allerdings findet auch hier ein Umschalten zwischen den verschiedenen Queues statt und auch die Effizienz wird nicht wesentlich erhöht.

Bei AMD kommen nun die asynchronen Compute Engines (ACE) ins Spiel. Diese mehrfachen Command Queues können gleichzeitig abgearbeitet und daher effizienter in den Rendering-Pipelines zusammengeführt werden. Damit das Beispiel des Autoverkehrs funktioniert, muss man vielleicht noch einfügen, dass es sich um einen getakteten Autoverkehr handelt, bei dem die Fahrzeuge einer bestimmten Reihenfolge und bestimmten Abständen folgen. Arbeiten die Command Queues alle mit dem gleichen Takt, kommt es eventuell zu Kollisionen. Die ACEs sollen dies verhindern, in dem sie die Commands unabhängig von einem Takt in die Queue einfügen. So lassen sich freie Lücken und damit brachliegendes Leistungspotenzial besser nutzen. Weiterhin möglich ist aber auch die Priorisierung bestimmter Prozesse.

Asynchronous Shaders sind bereits ein Teil der GCN-Architektur und es ist auch nicht weiter verwunderlich, dass eine GPU-Architektur derart vorausberechnend entwickelt wird. Die Ingenieure bei allen CPU- und GPU-Herstellern arbeiten sozusagen immer vorausschauend und planen bereits mit Softwareumsetzungen, die erst in einigen Jahren Anwendung finden werden.

Die ACEs sind bereits Bestandteil der "Graphics Core Next"-Architektur. Im Falle der "Hawaii"-GPU sind acht ACEs, mit der Möglichkeit jeweils acht Queues abzuarbeiten, vorhanden. Alle Grafikkarten aus dem Hause AMD mit GCN-Architektur sollen über diese ACEs verfügen, wobei sich die Anzahl natürlich abhängig vom Ausbau der Architektur unterscheidet.

Acht asynchrone Compute Engines (ACE) stehen in der "Hawaii"-GPU zur Verfügung, die allesamt unabhängig voneinander arbeiten können. Jede dieser ACEs kann wiederum acht unabhängig voneinander arbeitende Queues aufbauen. Für den schnellen Zugriff auf Daten können alle ACEs direkt auf den L2-Cache zugreifen. Über die Dual-DMA-Engine ist dies auch auf den Arbeitsspeicher möglich. Mit 16 GB pro Sekunde wird die volle Bandbreite von PCI-Express-3.0 ausgenutzt.

Asynchronous Shader sollen aber nicht nur die grundsätzliche Performance aktueller Architekturen und Arbeitsweisen von Render-Engines verbessern, sondern auch in speziellen Themenfeldern Verbesserungen herbeiführen. Das Aufkommen der VR-Technologie stellt alle damit beteiligten Hersteller vor neue Herausforderungen, denen prinzipiell auf eine ähnliche Art und Weise begegnet wird - egal ob von AMD oder NVIDIA. Um die Immersion, also das Eintauchen in eine virtuelle Welt störungsfrei gestalten zu können, müssen verschiedene Faktoren übereinstimmen.

Eine möglichst hohe Auflösung der Displays bei einer möglichst hohen Bildwiederholungsrate sind eine Herausforderung an die Rechenleistung als solches. Eine Auflösung von UltraHD pro Auge bei 90 Bildern pro Sekunde gelten momentan als das vorläufige Optimum. Die dazu notwenige Rechenleistung soll durch die Asynchronous Shader bereitgestellt werden. Zusätzlich reduziert sich die Latenz zwischen Eingabe durch den Nutzer und Darstellung auf dem Display, was für die Immersion ein entscheidender Faktor ist.

Mit den Asynchronous Shader ermöglicht werden auch weitere Technologien. Auf die Funktionsweise von Image Warping und (Asynchronous) Timewarp sind wir in anderen Artikeln schon genauer eingegangen. Die Herausforderungen und Lösungsansätze sind bei AMD und NVIDIA vergleichbar bzw. sogar identisch.

Nun darf man sich sicherlich die Frage stellen, wann und wie sich konkrete Vorteile für Spieler aus den Asynchronous Shader ergeben. Praxisbeispiele sind derzeit noch nicht anzuwenden und auch die bisherigen DirectX-12-Benchmarks sind allenfalls Orientierungen, da sie nur Teilbereiche der Render Pipeline beleuchten können. Bestes Beispiel sind wieder einmal die Draw Calls, deren Anzahl sich im Vergleich zwischen DirectX 11 und Mantle/DirectX 12 dramatisch erhöhen, deren Auswirkungen auf die komplette Render Pipeline aber noch nicht abzuschätzen sind.

Wir werden uns wohl noch gedulden müssen, bis die ersten echten DirectX-12-Anwendungen verfügbar sind, um die Auswirkungen nachvollziehen zu können. Wie groß der Einfluss der Asynchronous Shader dabei ist, versucht AMD in eigenen Benchmarks nachvollziehbar zu machen. Dabei soll in einem Beispiel aus dem LiquidVR-SDK die Leistung ohne Asynchronous Shader mit zugeschalteten Post-Processing-Effekten von 245 auf 158 fps sinken. Werden die Asynchronous Shader nun wieder aktiviert, erreicht die Leistung wieder ein Niveau wie ohne die Post-Processing-Effekte.

AMD hat nun also in der Theorie erklärt, wie ein Teil des Leistungs-Zugewinns mit DirectX 12 bei bestehender Hardware erreicht werden soll. Weiterhin schuldig bleibt man aber den konkreten Nachweis. Synthetische Benchmarks sind das eine und sprechen von einem Plus von teilweise mehreren hundert Prozent. Dabei werden aber nur Teilaspekte und niemals ein eventuelles Leistungsplus der kompletten Plattform beleuchtet. Dabei ergeht es allerdings nicht nur AMD so, sondern auch allen Anbietern vermeintlicher DirectX-12-Hardware. Mit der Windows 10 Technical Preview sowie den dazugehörigen Treibern wären die notwendigen Voraussetzungen in technischer Hinsicht erreicht, nun fehlt es noch an der Software.

Bei der Frage nach der Unterstützung durch die Hardware sind aber ebenso noch einige Fragen offen. Vermutlich wird es wieder unterschiedliche Ebenen für die Unterstützung von DirectX 12 geben. Mit unterschiedlichen Feature-Leveln hatten wir bereits bei DirectX 11 zu kämpfen und daran wird sich wohl auch mit DirectX 12 nichts tun. Sowohl AMD als auch NVIDIA benennen zumindest ihre letzten beiden GPU-Generationen als kompatibel zu DirectX 12. Im welchem Umfang dies der Fall sein soll, ist derzeit aber noch nicht bekannt.

Mit den Asynchronous Shader gibt AMD einen interessanten Einblick in das Verbesserungspotenzial durch DirectX 12. Die dazugehörige Hardware vorausgesetzt besteht also großes Potenzial für Leistungsverbesserungen, die nun allerdings noch umgesetzt werden müssen. Vermutlich werden wir erst im Sommer und mit ersten DirectX-12-Updates der Spiele (oder reinen DirectX-12-Engines) das Ergebnis der Anstrengungen durch AMD und NVIDIA sehen.

Welche GPUs die Asynchronous Shader nun in welcher Form genau unterstützen, erläutert folgende Tabelle:

Natürlich arbeitet auch NVIDIA an einer ähnlichen Technologie bzw. hat diese mit HyperQ bereits 2012 für den professionellen Bereich vorgestellt. Gegenüber "Fermi" ließ sich "Kepler" mit mehr als nur einer Work-Queue füttern. Bis zu 32 virtuelle GPU-Kerne können so erstellt und mit Daten versorgt werden. Die Implementierung unterscheidet sich allerdings bei AMD und NVIDIA, sodass die absoluten Zahlen sich nicht direkt vergleichen lassen.

AMD erklärt die Funktionsweise der Asynchronous Shader und einen Demo-Vergleich in zwei Videos: