Nvidia GeForce GTX 1080 Founders Edition: Pascal im Test

Inhaltsverzeichnis

<< >>

Die SMP-Engine (Simultaneous Multi-Projection)

Etliche GP104-Aspekte beeinflussen die Performance jedes Games, das wir heute testen – die erhöhte Kernanzahl, die Taktfrequenz und die Integration von zehn GBit/s schnellem GDDR5X. Andere Features können derzeit noch nicht demonstriert werden, dürften aber zukünftig große Auswirkungen zeigen. Solche Aspekte sind in einem Test immer sehr schwer einzustufen. Nichtsdestotrotz bringt die Pascal-Architektur verschiedene Funktionen mit, von denen wir gar nicht abwarten können, dass sie von am Markt verfügbaren Spielen genutzt werden.

Das erste, weiter oben bereits erwähnte Feature nennt Nvidia ‘Simultaneous Multi-Projection Engine’ (SMP). Dabei handelt es sich um einen Hardware-Block, der zu den PolyMorph-Engines der GP104 hinzugefügt wurde. Dieser Logikschaltkreis schnappt sich die Geometriedaten und verarbeitet sie für bis zu 16 Projektionen (Viewports) von einem einzelnen Sichtpunkt aus. Oder er erzeugt einen Versatz des Sichtpunkts für Stereo-Anwendungen und repliziert dabei die Geometrie bis zu 32 mal in Hardware – und zwar ohne den heftigen Performance-Overhead, der auftreten würde, wenn man den gleichen Effekt ohne SMP zu erzielen versuchen würde.

Aber gehen wir mal einen Schritt zurück und geben dem Ganzen etwas Kontext: Unser US-Kollege Chris zockt und arbeitet fast ausschließlich an drei Monitoren in einer Surround-Konfiguration. Wie bei vielen Nutzern solcher Setups sind Chris’ Monitore nach innen geneigt, um den Schreibtisch – übertrieben gesagt – zu „umfassen“. Das macht schon allein aus Office-Produktivitätsgründen Sinn. Games wissen das jedoch nicht. Eine Straße, die alle Displays durchläuft, hat an jedem Rahmen einen Knick – und ein runder Tisch im Peripheriebereich der Anzeige erscheint verzogen.

Um das Bild bei Chris’ Konfiguration korrekt darzustellen, bräuchte man eine Projektion geradeaus, eine zweite Projektion nach schräg links (so wie in einem Panorama-Cockpit eines Flugzeugs) und schließlich eine dritte Projektion, die schräg nach rechts orientiert ist. Die vorher abknickende Straße könnte so begradigt werden und man hätte zudem ein deutlich weiteres Sichtfeld. Die ganze Szene muss natürlich immer noch berechnet werden, aber man spart sich den beim dreifachen Rendern der Szene entstehenden Setup-, Treiber- und GPU-Frontend-Overhead.

Damit das klappt, muss eine Anwendung breite FOV-Settings unterstützen und SMP-API-Calls nutzen. Im Klartext: Spieleentwickler müssen das neue Feature annehmen und umsetzen, bevor man es als Endkunde nutzen kann. Wir können nicht exakt abschätzen, wie viel Zeit, Energie und Anstrengungen darauf verwendet werden wird, die (noch) recht kleine Zielgruppe der Surround-Gamer zufriedenzustellen. Aber es gibt andere Anwendungen, bei denen eine sofortige Implementierung Sinn macht.

Schauen wir uns mal die Virtual Reality an: Hier braucht man bereits eine Projektion pro Auge. Momentan rendern Games eine Szene einfach zweimal (je einmal pro Schirm/Auge), was all die oben erwähnten Ineffizienzen mit sich bringt. Aber da SMP ein Paar Projektionszentren unterstützt, können beide dank eines Features namens ‘Single Pass Stereo’ in einem einzelnen Durchgang gerendert werden. Die Vertex-Berechnung geschieht nur ein einziges mal und SMP schickt zwei Positionen zurück, die mit dem linken und rechten Auge korrespondieren. SMP kann außerdem zusätzliche Projektionen verwenden um ein Feature zu aktivieren, das als ‘Lens Matched Shading’ bezeichnet wird.

Kurz zusammengefasst versucht Lens Matched Shading VR-Berechnungen effizienter zu machen, indem ein Großteil der Arbeit vermieden wird, der normalerweise beim Rendern einer traditionellen, planaren Projektion anfallen würde – und zwar bevor die Projektion gebeugt wird, um sie an die Verzerrung der HMD-Linsen anzupassen (wodurch Pixel an den Stellen verschwendet werden, an denen die Beugung am stärksten ausgeprägt ist).

Indem SMP genutzt wird, um die Displayregion in Quadranten einzuteilen, kann dieser Vorgang deutlich verbessert werden. Anstatt eine quadratische Projektion zu rendern und diese dann zu manipulieren, erstellt die GPU Bilder, die bereits dem Ergebnis des Verzerrungsfilters der Linsen entsprechen. So wird verhindert, dass mehr Pixel generiert werden als nötig. Und so lange Entwickler die Mindestanforderungen der Sampling-Rate eines HMD pro Auge erreichen oder übertreffen, soll man keinen qualitativen Unterschied feststellen können. Nvidia bereitet nach eigener Aussage die Freigabe eines SDK vor; man wird also abwarten müssen, wie gut diese Features dann letztendlich unterstützt werden.

Wenn man Single Pass Stereo Lens Matched Shading kombiniert, soll laut Nvidia im Vergleich zu einer GPU ohne SMP die doppelte Performance in VR-Anwendungen drin sein. Ein Teil entstammt Verbesserungen des Pixeldurchsatzes: Unter Nutzung von Lens Matched Shading, um die Arbeit an Pixeln zu vermeiden, die nicht gerendert werden müssen, verringert Nvidias konservative Voreinstellung eine 4,2-MPix/s-Arbeitslast (Oculus Rift) auf 2,8 MPix/s und setzt damit einen ordentlichen Teil GPU-Shading-Performance frei – eine GPU ohne SMP müsste im Vergleich die anderthalbfache Leistung erbringen. Anschließend wird die Geometrie dank Single Pass Stereo nur ein einziges mal berechnet und auf beide Linsen verteilt (eine GPU ohne SMP müsste diese Berechnung für jedes Auge einzeln durchführen), so dass effektiv die Hälfte der Geometrieberechnungen im Vergleich zum aktuellen Ansatz wegfällt.

Wer von Jen-Hsuns Folie „2x Perf and 3x Efficiency Vs. Titan X” während des GTX-1080-Livestreams beeindruckt war, weiß nun, wie diese Zahlen zustande kamen.

Asynchronous Compute

Die Pascal-Architektur beinhaltet außerdem einige Änderungen bezüglich Asynchronous Compute – und das passiert aus mehreren Gründen (DirectX 12, VR und AMDs diesbezüglicher Vorsprung in Sachen Architektur) zu einem sehr passenden Zeitpunkt.

Mit seiner Maxwell-Architektur unterstützte Nvidia eine statische Partitionierung der GPU, um überlappenden Grafik- und Compute-Workloads gerecht zu werden. Theoretisch war dies ein guter Weg, um die Nutzung zu maximieren – zumindest solange beide Segmente aktiv waren. Wenn man 75 Prozent der GPU für Grafikberechnungen reserviert und dieses Segment dann Däumchen dreht, weil es darauf wartet, dass die Compute-Seite fertig wird, „verbrennt“ man jedweden theoretischen Vorsprung, der beim gleichzeitigem Ablauf beider Aufgaben drin wäre. Pascal adressiert dieses Problem mit einer Art dynamischem Lastverteilung. GPU-Ressourcen können immer noch zugewiesen werden – aber wenn der Treiber entscheidet, dass eine Sektion nicht voll genutzt wird, darf die andere übernehmen und fertig werden, so dass es keine negative Beeinträchtigung der Performance durch Verzögerungen gibt.

Nvidia hat außerdem die Preemption-Kompetenzen von Pascal verbessert – also seine Fähigkeit, eine Aufgabe zu unterbrechen, um eine andere, zeitkritische Aufgabe mit sehr niedriger Latenz anzugehen. Wir ihr wisst, sind GPUs hoch parallelisierte Gebilde mit großen Puffern, die diese gleichartigen, dicht an dicht sitzenden Ressourcen beschäftigt halten sollen. Ein Shader im Leerlauf nützt niemandem was – also packt man Arbeit in eine Warteschlange, um sie möglichst schnell durch die Grafik-Pipeline zu schicken. Aber nicht alles, was eine GPU so erledigt – vor allem heutzutage – ist so tolerant bezüglich Verzögerungen.

Ein perfektes Beispiel dafür ist das ‘Asynchronous Timewarp’-Feature (ATW), das Oculus für den Launch seiner Rift aktiviert hat. Für den Fall, dass die Grafikkarte nicht alle 11 Millisekunden ein frisches Frame auf einem 90-Hz-Display ausgeben kann, generiert ATW unter Nutzung der aktuellsten Arbeit des Rendering-Threads ein Zwischenbild, das noch entsprechend der Kopfposition korrigiert wird. Allerdings muss dieses Feature genug Zeit haben, um eine Timewarp-Frame zu erzeugen – und leider ist die Grafikvorhersage nicht wirklich feinkörnig.

Die Fermi-, Kepler- und Maxwell-Architekturen unterstützen lediglich die Draw-Level-Preemption – sie können also nur bei Draw Calls schalten und halten so ATW potenziell auf. Preemption-Anfragen müssen daher konsequent sehr früh gestellt werden, um rechtzeitig Kontrolle über die GPU zu garantieren, damit noch vor dem Display-Refresh ein Timewarp-Frame ausgegeben werden kann. Das ist wiederum in sich die Quadratur des Kreises – denn ATW soll seine Arbeit ja so spät wie möglich tun; letztlich will man ja ein „echtes“ frisches Frame.

Pascal implementiert nun zusätzlich eine deutlich feinere Pixel-Level-Preemption für Grafik – GP104 kann jederzeit seine Arbeit auf dem Pixel-Level stoppen, den Status der Pipeline sichern und den Kontext wechseln. Anstelle der Vorhersage im Millisekundenbereich, über die Oculus schreibt, will Nvidia mit weniger als 100 Mikrosekunden arbeiten.

Die Maxwell-Architektur unterstützte bereits das Äquivalent von Pixel-Level-Preemption auf der Compute-Seite, indem Thread-Level-Granularität aktiviert wurde. Pascal hat diese Funktion natürlich ebenfalls an Bord, erweitert sie aber um Instruction-Level-Vorhersagen in CUDA-Compute-Aufgaben. Nvidias Treiber beinhalten diese Funktion derzeit zwar noch nicht, aber das Feature sollte zusammen mit der Pixel-Level-Vorhersage in Kürze über den Treiber vollumfänglich zugänglich sein.

Ebenfalls interessant...

Seiten:

Tags: , , , ,

Schreibe einen Kommentar

Privacy Policy Settings

Google Analytics Wir sammeln anonymisierte Daten darüber, welche Beiträge und News gelesen werden. Wir ermitteln dabei auch die Zeit - ebenfalls anonymisiert - wie lange ein Beitrag gelesen wurde. Dadurch können wir einfacher Themen anbieten, die Sie interessieren.
This website stores some user agent data. These data are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to opt-out of any future tracking, a cookie will be set up in your browser to remember this choice for one year. I Agree, Deny
600 Verbiete Google Analytics, mich zu verfolgen