Alex Vlachos von Valve : „Jedes VR-Spiel sollte Multi-GPU unterstützen“

, 59 Kommentare
Alex Vlachos von Valve: „Jedes VR-Spiel sollte Multi-GPU unterstützen“
Bild: Alex Vlachos

Alex Vlachos, VR-Softwareentwickler bei Valve, hat zur GDC 2016 über die Hardwareanforderungen von VR-Spielen, deren Optimierung und Multi-GPU-Systeme gesprochen. Sein Fazit: Jedes VR-Spiel sollte Multi-GPU unterstützen. Allerdings nicht, um die Bildwiederholrate zu erhöhen. Ein Plugin für Unity soll Entwicklern helfen.

AMD und Nvidia haben mit LiquidVR und GameWorks VR APIs bereitgestellt, die es Entwicklern ermöglichen, Multi-GPU-Systeme in VR-Spielen optimal einzubinden. Die APIs erlauben es, die von der CPU für beide Augen bereitgestellten Zeichenbefehle (Draw Calls) zielsicher auf beide GPUs aufzuteilen. Weil die von den Studios bisher verwendeten Engines diese Erweiterungen noch nicht unterstützen, liegen Multi-GPU-Systeme in den ersten VR-Spielen allerdings noch brach.

Für Vlachos ist das ein Versäumnis, das nachgeholt werden sollte. Ziel sei es dabei allerdings nicht, Spiele überhaupt erst lauffähig zu machen, vielmehr sollte die Mehrleistung dazu genutzt werden, die Darstellungsqualität gegenüber leistungsschwächeren Rechnern zu erhöhen. Richtig umgesetzt, könnten Dual-GPU-Systeme mit der zweifachen Auflösung und Quad-GPU-Systeme mit der drei bis vierfachen Auflösung fertig werden und dabei die benötigte Rechenzeit eines Single-GPU-Systems bei einfacher Auflösung noch unterbieten. Zu bedenken gibt Vlachos allerdings, dass die Treiber-Last für die CPU bei mehr als zwei GPUs hoch ausfallen könnte – weiter darauf ein ging er in seinem knapp einstündigen Vortrag aber nicht.

Mehr Pixel in derselben Zeit durch Multi-GPU-Systeme
Mehr Pixel in derselben Zeit durch Multi-GPU-Systeme (Bild: roadtovr.com)

Spiele müssen die Qualität an die Hardware anpassen

Voraussetzung für die sinnvolle Nutzung von Multi-GPU-Systemen sei die Fähigkeit einer Engine, sich ohne Eingriff des Anwenders an die Hardware anzupassen. Und zwar ohne den Detailreichtum der virtuellen Welt anzupassen, wie es Presets in klassischen PC-Spielen erlauben. Auf diesem Weg ließen sich nicht nur stärkere Rechner für eine höhere Darstellungsqualität nutzen, auch könnten schwächere Rechner mit weniger Qualität die erforderlichen 90 FPS noch halten.

Im SteamVR Performance Benchmark nutzt Valve bereits die variable Darstellungsqualität, auch langsamere Grafikkarte erreichen hier die erforderlichen 90 FPS – das anschließende Testergebnis in Form eines Punktestandes fällt für diese Modelle trotzdem niedrig aus, weil in der virtuellen Welt sichtbare Einschnitte hingenommen werden müssen. Trotzdem schafft es heute bereits eine GeForce GTX 680, den Benchmark flüssig wiederzugeben, wohingegen vor einem Jahr noch eine GeForce GTX 980 notwendig war.

Anpassungen, die Engines zu diesem Zweck vornehmen, können die tatsächlich gerenderte Auflösung (Supersampling), das verwendete Kantenglättungsverfahren oder die Nutzung der zwei folgenden Verfahren zur Leistungssteigerung sein.

Mehr Pixel für den Fokus, weniger für die Peripherie

Ein probates Mittel ist, im peripheren Sichtfeld weniger Pixel 1:1 zu berechnen, weil das menschliche Auge an den Seiten des Sichtfeldes weniger Details wahrnimmt. Weil der Fokus weniger Fläche umfasst als das periphere Sichtfeld, bietet sich in der Technik potentiell eine weitere Möglichkeit zur Nutzung mehrerer GPUs, indem die eine den Fokus des einen Auges und die andere die Ränder des Sichtfeldes berechnet – die resultierende Last könnte annähernd identisch ausfallen.

Pixel erst auslassen und am Ende ergänzen

Noch eine Stufe weiter geht der Gedanke, im peripheren Sichtfeld Pixel in einem Schachbrettmuster ganz aus der Berechnung zu lassen und die Anzahl der zu berechnenden Bildpunkte in diesem Bereich im ersten Schritt so zu halbieren. Auf Basis des berechneten Schachbretts könnten die Lücken anschließend näherungsweise gefüllt werden, wobei ein Leistungsgewinn nur zu Stande kommt, wenn diese Näherung weniger Rechenleistung als die originäre Berechnung der Pixel erfordert. In Aperture Robot Repair will Valve aktuell mit einem Prototypen der Technik gut fünf bis fünfzehn Prozent Leistung gewonnen haben.

Welche Möglichkeiten bestehen, dasselbe Spiel auf unterschiedlich starken Systemen anders berechnen zu lassen, präsentierte Vlachos erneut anhand der Demo Aperture Robot Repair. Auf dem potentesten System kann die Demo intern mit 1,4-facher Auflösung und unter Verwendung von 8×MSAA berechnet werden, auf dem schwächsten liegt die Auflösung 35 Prozent unter der nativen Auflösung der Brille, MSAA wird auf 4× reduziert und im peripheren Sichtfeld werden 50 Prozent der Pixel ausgelassen.

Robot Repair in elf verschiedenen Anforderungsstufen
Robot Repair in elf verschiedenen Anforderungsstufen (Bild: roadtovr.com)

Explizit rät Valve Entwickler dazu, bei der Beurteilung der Last nicht die eigene Engine sondern das Headset heran zu ziehen, weil Treiber und SteamVR weitere Zeit für die Berechnung benötigen. SteamVR stellt die erforderlichen Informationen allerdings zur Verfügung. Grundsätzlich sollten Entwickler versuchen, die Last zwischen 70 und 90 Prozent zu halten, um weder die Hürde von 90 FPS pro Sekunde zu reißen, noch auf Grafikqualität verzichten zu müssen.

Valves Ansatz gegen ausgelassene Bilder

Um gegen ultimativ doch einmal ausgelassene Bilder vorzugehen, nutzt Oculus seit März 2015 eine Funktion namens Asynchronous TimeWarp (ATW). Sie ermöglicht es Engines, anstelle eines komplett neuen Frames einen Alten an die aktuelle Ausrichtung des Spielers anzupassen. So wird vermieden, dass die Bewegungen des Spielers verzögert umgesetzt werden. Das geschieht auf aktuellen GPUs parallel zum Berechnen des neuen Frames, so dass die Alternative sofort bereitsteht, sollte sich das neue Frame als zu aufwendig für die Ausgabe innerhalb der erforderlichen 11,1 ms erweisen.

Das Problem: Dabei wird nur die neue Position der Augen berücksichtigt, nicht aber die des Kopfes. Der Spieler erhält damit zwar immer einen vollständigen Bildausschnitt in der Brille, die Perspektive ist aber falsch. Kommt alternativ die neue Position des Kopfes zum Einsatz, muss das Bild in Teilen neu ausgerichtet werden, was für Risse sorgt, die gefüllt werden müssen. Bereits im März 2015 sprach Oculus deshalb lediglich von einem Sicherheitsnetz, das gegenüber dem Auslassen einzelner Bilder nicht einmal für eine bessere Wahrnehmung sorgen muss. Und von alten GPUs auch nicht unterstützt wird.

In the worst cases, ATW’s artifacts can cause users to have an uncomfortable experience. Or stated differently: in the worst cases, ATW can’t prevent an experience from being uncomfortable.

Oculus zu Timewarp

Der Ansicht schloss sich Vlachos zur GDC an. Mit zukünftigen GPUs könnte die asynchrone Neuausrichtung alter Bilder zwar weiter perfektioniert werden, aktuell sollten Entwickler aber unter allen Umständen versuchen, Bilder erst gar nicht auslassen zu müssen. Nichtsdestoweniger gibt es die Funktionalität jetzt auch in OpenVR, der Basis von SteamVR.

Mit Interleaved Reprojection Hint hat Vlachos darüber hinaus eine weitere Alternative präsentiert, die auch auf alten GPU-Generationen genutzt werden kann. In diesem Fall können Anwendungen die Neuausrichtung bereits berechneter Bilder als Alternative zur Berechnung neuer Bilder anstoßen, die zur Verfügung stehende Zeit beträgt 18 Millisekunden und damit weniger als 22,2 Millisekunden bis zur Berechnung eines vollständig neuen Bildes. Eine Lösung für dauerhaft zu niedrige Bildwiederholraten ist aber auch das nicht.

Adaptive Qualität wird Plugin für Unity

Um Entwicklern zu helfen, wird Valve die aufgezeigten Möglichkeiten, um die Qualität des Spiels in Echtzeit an die Leistungsfähigkeit des Rechners anzupassen, schon in Kürze als Plugin für die Engine Unity bereitstellen. Die meisten der kleinen Entwickler setzen aktuell auf diese Basis und könnten in ein, bis zwei Wochen mit der Optimierung der Spiele auch für schwächere Systeme beginnen.

Multi-GPU ist wiederum weiterhin Aufgabe der Entwickler oder der Engine. Mehrere Entwickler gaben gegenüber ComputerBase zu verstehen darauf zu warten, dass Liquid SDK oder GameWorks VR in Unity integriert worden sind.