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

Veröffentlicht am: von

Ashes of the SingularityDirectX 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.

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.

Die Asynchronous Shaders

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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 bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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.

Asynchronous Shader bei AMD
Asynchronous Shader bei AMD

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:

Support der Asynchronous Shader
Architektur Mixed-Mode GPU-Computing
AMD GCN 1.2 (R9 285) 1x Grafik + 7x Compute 8x Compute
AMD GCN 1.1 (R9-290-Series) 1x Grafik + 7x Compute 8x Compute
AMD GCN 1.1 (R7-260-Series) 1x Grafik + 1x Compute 2x Compute
AMD GCN 1.0 (HD-7000- und restliche 200-Series) 1x Grafik + 1x Compute 2x Compute
NVIDIA Maxwell 2. Generation (GTX-900-Series) 1x Grafik + 31x Compute 32x Compute
NVIDIA Maxwell 1. Generation (GTX-750-Series) 1x Grafik 32x Compute
NVIDIA Kepler (GK110) 1x Grafik 32x Compute
NVIDIA Kepler (GK10x) 1x Grafik 1x Compute

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:


Bisher konzentrierte sich vieles bei der Berichterstattung über DirectX 12 auf die Low-Level-Natur der API sowie den geringeren Overhead und damit das freiwerdende Leistungspotenzial. Auch wir haben bereits einige Tests durchgeführt – einmal zum entsprechenden Draw-Call-Test des 3DMark von Futuremark und inzwischen gehört ein DirectX-12-Benchmark zum Grafikkarten-Testparcours. Über die gemeinsame Nutzung der Grafik-API von AMD- und NVIDIA-Grafikkarten haben wir bereits berichtet, aber bis auf die theoretische Möglichkeit war davon bisher wenig zu sehen.

Ein gewöhnungsbedürftiger Anblick: Je eine AMD- und NVIDIA-Grafikkarte im Test
Ein gewöhnungsbedürftiger Anblick: Je eine AMD- und NVIDIA-Grafikkarte im Test

DirectX 12 Multi-GPU Explicit Multi-Adapter oder Multi Display Adapter – so die meistgenannten Namen der Methode der gemeinsamen Zusammenarbeit unterschiedlicher GPUs – wird durch die tiefere Kontrolle der API durch die Entwickler möglich. Sie haben eine weitergehende Kontrolle über den Zugriff auf den Speicher und viele andere Elemente der Hardware. Der Betrieb eines Multi-GPU-Systems lag unter DirectX 11 in den Händen der Treiber-Entwickler. Mit DirectX 12 geht die Kontrolle auf die Spiele-Entwickler über.

Die Multi-GPU-Technik

Doch zunächst noch ein paar Worte zur Historie der Multi-GPU-Technik: Die Entwicklung von PCI-Express als Interface zur Kommunikation der Grafikkarten mit dem restlichen System hat dazu geführt, dass sowohl AMD als auch NVIDIA mithilfe des AFR (Alternate Frame Rendering) eine relativ einfache Implementation der Multi-GPU-Technik einführen konnten. Beim AFR wird jeweils ein Frame von einer GPU berechnet. Anpassungen des Spiels oder der Game-Engine sind nicht notwendig. Einzig AMD und NVIDIA müssen ihre Treiber entsprechend anpassen, damit Unterschiede im Rendering einzelner Frames nicht zu störenden Effekten führen. AMD führte dazu das Frame Pacing ein, bei NVIDIA sind entsprechende Techniken ebenfalls bereits in Hard- und Software gegossen. Die Synchronisation zwischen GPU und Display-Panel in Form von FreeSync und G-Sync hat dazu geführt, das weitere störende Effekte zumindest minimiert werden konnten.

Allerdings sind die Hardwaremöglichkeiten relativ eingeschränkt. NVIDIA erlaubt nur die Zusammenarbeit zwischen identischen Grafikkarten, während AMD etwas flexibler zumindest die Möglichkeit bietet unterschiedliche Grafikkarten einzusetzen, die auf der gleichen GPU basieren (z.B: Radeon R9 290 und Radeon R9 290X). Der wichtigste Grund für diese Einschränkung ist natürlich die Tatsache, dass so die Frames im AFR immer ähnlich schnell berechnet werden können. Anläufe mit dem SFR (Spit Frame Rendering) wurden zwar gemacht, setzten sich aber nicht durch. Zum SFR aber später mehr.

Doch abgesehen von den offiziellen Modi SLI und CrossFire gab es auch Anläufe Grafikkarten verschiedener Hersteller und unterschiedlicher Leistungsklassen zu kombinieren. 2010 führte LucidLogix die Hydra-Technologie ein. Mit einem Zusatzchip und dazugehöriger Software setzte sich die Technologie zwischen die Calls von DirectX und OpenGL und führte diese den kompatiblen Grafikkarten zu. Allerdings gab es auch große Einschränkungen, sowohl auf Seiten der Hardware, als auch auf Seiten der Software. Letztendlich führte dies dazu, dass sich die Hydra-Technologie nicht durchsetzen konnte und wieder in der Versenkung verschwand.

DirectX 12 und Multi-Adapter

Mit DirectX 12 führt Microsoft drei Multi-Adapter-Modi ein. Der einfachste beschreibt dabei die bereits bekannte Funktionalität im AFR mit gleichen Grafikkarten wie bisher bei AMD und NVIDIA. Dieser Modus limitiert allerdings die Möglichkeiten der Entwickler, reduziert aber auch das Fehlerpotenzial bei tiefergehenden Zugriffen auf die Hardware. Weiterhin wird ein Großteil der Arbeit vom Treiber übernommen und nicht von DirectX 12.

Präsentation zu EMAPräsentation zu EMA

Präsentation zu EMA in DirectX 12

DirectX 12 ermöglicht einen tiefergehenden Zugriff auf die Hardware, auch in einem Multi-GPU-System. Dazu hat Microsoft auch den Explicit-Multi-Adapter-(EMA)-Modus eingeführt. Dazu müssen die Spieleentwickler explizit auf eine Multi-GPU-Unterstützung hinarbeiten. Jede einzelne GPU, die Speicherzugriffe und wie die GPUs untereinander kommunizieren – all dies muss zuvor festgelegt werden. Die Verantwortung der Funktionalität liegt vollständig in Händen der Spieleentwickler, was auch gewisse Gefahren birgt. Der Aufwand dieser expliziten Anpassungen darf nicht unterschätzt werden und Fehler müssen von den Entwicklern und nicht durch Microsoft, AMD oder NVIDIA korrigiert werden.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Der EMA-Modus bietet aber auch noch zwei unterschiedliche Wege der Implementierung: Linked Mode und Unlinked Mode. Der Unlinked Mode stellt die Basis der Funktionalität von EMA dar. Der Linked Mode auf der anderen Seite bietet eine höhere Funktionalität, schränkt dann aber auch die kombinierbare Hardware deutlich stärker ein – das ist wie ein festgelegtes SLI und CrossFire für DirectX 12 zu verstehen. Der Unlinked Mode hingegen kann dazu verwendet werden, unterschiedliche Grafikkarten, auch von unterschiedlichen Herstellern, miteinander zu kombinieren. Auch die Kombination zwischen diskreten und integrierten GPUs ist möglich.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Im Unlinked Mode wird jede Grafikkarte als eigenständige Hardware, mit eigenem Speicher, eigenem Commandprozessor etc. angesehen. Das EMA in DirectX 12 ermöglicht aber nun den Datenaustausch zwischen diesen Instanzen und dies tiefergehend als nur der Austausch fertig gerenderter Frames. Teilweise gerenderte Frames oder Daten in den Buffern können nun ausgetauscht werden, was völlig neue Wege des Renderings auf mehreren GPUs ermöglicht.

Was sich auf den ersten Blick aber wie eine einfache Möglichkeit des Datenaustausches darstellt und damit weiter als alles geht, was bisher möglich war, wird auf den zweiten Blick doch etwas komplizierter. So werden die Daten über das PCI-Express-Interface ausgetauscht, was im Vergleich zur Kommunikation zwischen GPU und dem Grafikspeicher deutlicher langsamer ist und zudem über eine recht hohe Latenz verfügt. Die Entwickler müssen sich also überlegen, welche Daten sie wann austauschen wollen, damit das PCI-Express-Interface nicht zum Flaschenhals wird. Ebenfalls darauf geachtet werden muss, in welcher Form diese Daten ausgetauscht werden. Die verschiedenen Hersteller und GPU-Generationen und Varianten legen oftmals unterschiedliche Datenformate an, die dann nicht so einfach untereinander verwendet werden können. Hier wird dann die Arbeit ersichtlich, die bei der Implementation von EMA im Unlinked Mode notwendig ist. Der Fokus des Unlinked Mode innerhalb des EMA liegt auf der bereits besagten Unterstützung von dGPUs und iGPUs, aber natürlich lassen sich hier auch unterschiedliche GPUs unterschiedlicher Hersteller kombinieren.

Präsentation zu EMA in DirectX 12
Präsentation zu EMA in DirectX 12

Der Linked Mode stellt wie gesagt in einfachster Form ein SLI oder CrossFire unter DirectX 12 dar, allerdings wird im Linked Mode die Hardware zu einer "Grafikkarte" zusammengefasst. Für das Spiel und den Nutzer sind nur noch eine GPU und ein Speicher sichtbar. Die Hardware muss dazu deutlich enger miteinander verknüpft werden, was mehr Möglichkeiten zulässt, allerdings auch für die Einschränkungen bei der Hardware sorgt. Das größte Leistungspotenzial liegt durch die Freiheiten sicherlich im Linked Mode, die größte Flexibilität bietet der Unlinked Mode. Entwickler, die möglichst wenig Arbeit haben möchten und dennoch eine Basisfunktionalität für ein Multi-GPU-System bieten wollen, unterstützen einfach nur das EMA und überlassen die Arbeit den Treiberentwicklern von AMD und NVIDIA. Da aber nur die Entwickler selbst den besten Einblick in die eigene Arbeit haben, ist sicherlich ein Angebot aus Linked und Unlinked Mode zu bevorzugen.

EMA in Ashes of the Singularity

Oxide Games hat Ashes of the Singularity vor einigen Monaten in den Early Access von Steam gebracht. 2016 soll das Echtzeit-Strategiespiel dann fertig sein. Als erstes seiner Art setzt es auf DirectX 12 und als erster Entwickler hat Oxide Games die Möglichkeiten von DirectX 12 vollständig ausgenutzt. AMD und Microsoft nutzen das Entwicklerstudio bzw. das Spiel als Technologiedemo. Zur Demonstration von EMA hat Oxide Games das Spiel auf eine AFR-Implementierung hin angepasst. Die Entwickler können jeden Frame einer bestimmten GPU zuteilen – eine Arbeit die zuvor vom Treiber übernommen wurde. Außerdem übernehmen sie die Übertragung der Frames von der sekundären zur primären GPU und auch das Frame Pacing wird nun vom Entwickler übernommen.

Das AFR funktioniert am besten, wenn ähnlich starke Grafikkarten eingesetzt werden, da die Frames hier in ähnlicher Zeit berechnet werden. Dennoch geht die Implementierung weiter als das, was AMD und NVIDIA derzeit bieten. Nicht nur lassen sich unterschiedliche GPUs unterschiedlicher Hersteller kombinieren, auch ist der Betrieb einer GeForce GTX Titan X mit einer GeForce GTX 980 Ti beispielsweise möglich. Funktionieren sollten alle Grafikkarten, die DirectX 12 unterstützen. Allerdings ist eine Kombination einer leistungsstarken mit einer eher leistungsschwachen Grafikkarte weniger sinnvoll. Wenn überhaupt, dann dürfte in der Praxis der Betrieb zweier fast gleichwertiger GPUs zu finden sein, womit auch die besten Resultate zu erwarten sind.

Ashes of the Singularity befindet sich in der Gesamtheit noch in einem Alpha-Status. Der Unlinked Mode von EMA ist noch weitaus experimenteller. Nur eine bestimmte Kombination aus AMD- und NVIDIA-Treibern funktioniert, aber das Ergebnis ist weitaus besser, als man dies zum aktuellen Zeitpunkt erwarten könnte. Laut Oxide Games soll der Unlinked Mode weiter verbessert werden, bevor man sich an die Arbeit mit dem Linked Mode macht. Von ihm erwartet man sich eine Leistungssteigerung im Bereich von 5 bis 10 Prozent.


Für alle Benchmarks haben wir unser Grafikkarten-Testsystem verwendet. Bei der Radeon R9 Fury X kam der aktuelle Radeon Software Crimson Edition 16.2 zum Einsatz, bei der GeForce GTX 980 Ti der GeForce 361.91. In den verschiedenen Auflösungen unterschieden wir in der Folge zwischen den jeweiligen Durchschnittswerten über die komplette Benchmarkszene und auch den unterschiedlichen Anforderungsprofilen.

Um den Unterschied zwischen der Anzahl von Heavy-, Medium- und Normal-Batches deutlich zu machen, ein paar Zahlen dazu. In den Szenen mit vielen Draw Calls (Heavy) werden etwa 22.000 bis 25.000 Batches/Draw Calls pro ms aufgerufen. In den Medium-Szenen sind es 6.500 bis 7.000 Draw Calls pro ms und bei den normalen Szenen 4.900 bis 5.200 Draw Calls pro ms.

Grafik-Menü von Ashes of SingularityGrafik-Menü von Ashes of Singularity

Grafik-Menü von Ashes of the Singularity

Obige Screenshots zeigen einen Einblick in das Grafik-Menü von Ashes of the Singularity.

Ashes of Singularity

1.920 x 1.080 Extreme-Preset - Durchschnitt

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

1.920 x 1.080 Extreme-Preset - Viele Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

1.920 x 1.080 Extreme-Preset - Medium Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

1.920 x 1.080 Extreme-Preset - Normal Draw Calls

Bilder pro Sekunde
Mehr ist besser

In den ersten Benchmarks schauen wir uns die Leistung der beiden Karten in einer recht niedrigen Auflösung von 1.920 x 1.080 Pixel an. Während unter DirectX 11 die GeForce GTX 980 Ti deutlich im Vorteil ist, überholt die Radeon R9 Fury X den Konkurrenten unter DirectX 12. Besonders auffällig ist dabei, dass je mehr Draw Calls verwendet werden, desto eher ist die Radeon R9 Fury X im Vorteil. Von der Aktivierung der Asynchronous Shaders profitiert in jedem Fall die Grafikkarte aus dem Hause AMD, während bei NVIDIA eher ein kleiner Leistungseinbruch zu verzeichnen ist.

Ashes of Singularity

2.560 x 1.440 High-Preset - Durchschnitt

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

2.560 x 1.440 High-Preset - Viele Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

2.560 x 1.440 High-Preset - Medium Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

2.560 x 1.440 High-Preset - Normal Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ein ähnliches Bild zeigt sich auch bei einer Auflösung von 2.560 x 1.440 Pixel. Die Radeon R9 Fury X profitiert durchgängig stärker von DirectX 12, zeigt unter DirectX 11 aber auch immer wieder die typische AMD-Schwäche beim Treiber, denn diesen hat NVIDIA immer wieder dahingehend optimiert, dass der Overhead unter DirectX 11 möglichst gering ist. Die Leistung unter DirectX 11 ist daher deutlich besser und dies zeigt sich auch bei vielen anderen DirectX-11-Spielen.

Ashes of Singularity

3.840 x 2.160 High-Preset - Durchschnitt

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

3.840 x 2.160 High-Preset - Viele Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

3.840 x 2.160 High-Preset - Medium Draw Calls

Bilder pro Sekunde
Mehr ist besser

Ashes of Singularity

3.840 x 2.160 High-Preset - Normal Draw Calls

Bilder pro Sekunde
Mehr ist besser

Da wir auch bei einer Auflösung von 3.840 x 2.160 Bildpunkten ein ähnliches Bild sehen, noch etwas Hintergrund zu den Erkenntnissen aus den Ergebnissen. AMD hat sich bereits vor einigen Jahren zur Entwicklung alternativer Grafik-APIs entschieden. Daraus ist auch Mantle entstanden, welches zwar ein offener Standard wurde, von NVIDIA oder anderen Herstellern aber nie ernsthaft in Betracht gezogen wurde. Da DirectX 12 hinsichtlich der Leistungsverbesserungen einen ähnlichen Ansatz wählt, scheint AMD von der Erfahrung deutlich zu profitieren.

Etwas anders sieht dies bei NVIDIA aus. Hier lag der Fokus lange Zeit auf der Verbesserung der Leistung unter den aktuellen Grafik-APIs. Natürlich war und ist man in der Entwicklung von DirectX 12 und auch Vulkan mit einbezogen, offenbar aber hat in der Gegenwart noch keine Auslegung in die Zukunft stattgefunden, was zum aktuellen Zeitpunkt einen Nachteil hinsichtlich der Leistung darstellt. Mit dem Erscheinen von mehr und mehr Titeln wird das sicherlich auch wieder kompensiert werden. NVIDIA wird und kann sich bei gleichwertiger Hardware nicht auf einen Leistungsnachteil im zweistelligen Prozentbereich berufen.


In der Theorie haben wir den Multi-GPU-Betrieb mit unterschiedlichen Grafikkarten bereits besprochen, nun schauen wir uns die dazugehörigen Leistungswerte an.

Ashes of Singularity

3.840 x 2.160 High-Preset

Bilder pro Sekunde
Mehr ist besser

In einem ersten Versuch wählten wir eine Auflösung von 3.840 x 2.160 Pixel im High-Preset. Damit ermöglichte eine zusätzlich installierte GeForce GTX 980 Ti bei einer schon installierten Radeon R9 Fury X ein Leistungsplus von 27,8 Prozent. Die GeForce GTX 980 Ti hingegen profitierte von der Radeon R9 Fury X durch ein Plus von 45,1 Prozent.

Allerdings bemerkten wir an dieser Stelle, dass Ashes of the Singularity offenbar selbst bei einer Auflösung von 3.840 x 2.160 Pixel noch durch den Prozessor limitiert wird. Der Benchmark selbst zeigt dies in der Auswertung, sodass eine entsprechende Analyse recht einfach war. Also entschieden wir uns für den Extreme-Preset und erhöhten damit die Last auf den GPUs noch etwas.

Ashes of Singularity

3.840 x 2.160 Extreme-Preset

Bilder pro Sekunde
Mehr ist besser

Im veränderten Setting profitierte die Radeon R9 Fury X von einer zusätzlich installierten GeForce GTX 980 Ti nun um 30,2 Prozent, während eine Radeon R9 Fury X einer schon installierten GeForce GTX 980 Ti zu einem Plus von 50,9 Prozent verhelfen konnte. Der Leistungszuwachs stieg also noch einmal etwas an.

Auswertung des integrierten Benchmarks in Ashes of Singularity
Auswertung des integrierten Benchmarks in Ashes of the Singularity

An dieser Stelle sei noch einmal auf den recht frühen Entwicklungsstatus von Ashes of the Singularity hingewiesen. Die verschiedenen Multi-GPU-Modi ohne die explizite Verwendung von SLI und CrossFire verlangen nach einer Menge Anpassungen durch die Spieleentwickler und hier besteht offenbar noch einiges an Optimierungspotenzial. Sicherlich spielt es auch eine Rolle, dass die dazugehörigen Implementierungen durch die Entwickler meist erstmals durchgeführt werden - es fehlt also an Erfahrung.


Die Entwicklungsschritte bei Oxide werden größer und das sollte auch der Fall sein, wenn ein Spiel am 22. März, also in knapp drei Wochen, erscheinen soll. Sowohl die "einfache" Portierung einer DirectX-12-Version als auch die weitergehende Unterstützung der Multi-GPU-Systeme machen große Schritte - ebenso die Leistungswerte.

Den größten Sprung hat sicherlich die Multi-GPU-Unterstützung gemacht. Hier haben wir uns aber im Besonderen auf den Mixed-Mode bestehend aus jeweils einer NVIDIA- und einer AMD-Grafikkarte konzentriert. Zwar wird die Verwendung von DirectX 12 auch beim klassischen CrossFire oder SLI eine Rolle spielen, die dazugehörigen Anpassungen sind aber von den Umsetzungen von AMD und NVIDIA abhängig. Multi-GPU-Systeme mit zwei unterschiedlichen Grafikkarten sind abhängig von den Optimierungen durch die Spieleentwickler und so werden wir hier von Spiel zu Spiel unterschiedliche Ergebnisse erhalten. Es dürfte allerdings nicht sehr oft vorkommen, dass ein Nutzer versuchen wird zwei in etwa gleichschnelle Grafikkarte von unterschiedlichen Herstellern in einem System zu kombinieren. Die Ergebnisse zeigen aber, dass dies eigentlich recht gut funktioniert.

Benchmark-Szene in Ashes of the Singularity

Kommen wir aber zum wichtigsten Teil: Der Single-GPU-Leistung. Hier zeigt sich in Ashes of the Singularity derzeit folgendes Bild: Während NVIDIA im Rendering unter DirectX 11 klar die Nase vorne hat, profitiert AMD offenbar von einer guten DirectX-12-Umsetzung. Umgekehrt gilt dies ebenso und zeigt damit letztendlich ein recht verzerrtes Bild der aktuellen Situation. Ashes of the Singularity ist dabei sicherlich nur eine Ausnahmesituation, denn für alle kommenden Spiele erwarten wir dieses Bild nicht und gerade NVIDIA wird alles versuchen, hier zumindest im Leistungsgewinn gleichauf zu liegen.

Auf die Asynchronous Shaders bezogen bleibt festzuhalten, dass AMD von der Implementation im Bereich von 8 bis 15 Prozent profitiert, während NVIDIA derzeit keinen Vorteil daraus ziehen kann. Laut NVIDIA sind die Asynchronous Shaders derzeit im Treiber auch noch nicht aktiviert - Umso interessanter wäre des nun, einen Treiber mit aktivierter Asynchronous-Shaders-Funktion in die Finger zu bekommen. Aber auch hier wird sich NVIDIA vermutlich nicht mehr lange Zeit lassen (können) und eine entsprechende Anpassung vornehmen.

Alles in allem bieten der neue Benchmark und die neue Beta von Ashes of the Singularity eine Möglichkeit für einen ersten Vergleich. Eine Probe "eins aus eins" bedeutet für eine größere Statistik aber wenig und so bleibt nur abzuwarten, bis weitere Spiele oder Tests erscheinen. Für einen fairen Vergleich muss das Feature-Set dann aber auch nahezu identisch sein.