GTC20

NVIDIA erläutert DLSS 2.0 im Detail

Vor wenigen Tagen stellte NVIDIA das DLSS 2.0 vor. In der Version 2.0 wurde das Deep Learning Super Sampling in der Darstellungsqualität auf ein Niveau gehoben, welches man bereits von Anfang an geplant hatte. Dazu mussten einige alte Zöpfe abgeschnitten werden, die unter anderem dazu führen, dass nur explizit auf DLSS 2.0 optimierte Spiele dies auch unterstützen. Ältere DLSS-Titel verwenden noch das ältere Verfahren.

Zunächst in der Theorie, dann aber auch im Praxiseinsatz haben wir uns das DLSS 2.0 angeschaut. In einer Präsentation der GPU Technology Conference hat NVIDIA nun über die technischen Aspekte hinter DLSS 2.0 gesprochen. Eine Bildverbesserung per AI, bei der bis zu 75 % der Pixel nicht auf der Hardware vor Ort gerendert, sondern eher durch den Algorithmus generiert werden, ist für viele Nutzer noch etwas schwer zu durchschauen.

Mit DLSS 2.0 macht es sich vor allem NVIDIA selbst etwas einfacher, da der Algorithmus bzw. das Deep-Learning-Netzwerk nicht mehr manuell angepasst und speziell auf ein Spiel ausgelegt werden müssen. DLSS 2.0 wird ständig weiterentwickelt und kann zu jedem Zeitpunkt von Spielen integriert und angewendet werden.

Am Anfang vergleicht NVIDIA die Bildqualität zwischen einem nativen Rendering, DLSS 1.0/1.9 und DLSS 2.0 – auch mit unterschiedlichen Skalierungsstufen.

Die Bildqualität mindestens auf Niveau eines nativen Renderings zu halten, ist einer der wichtigsten Aspekte hinter DLSS 2.0. Ein weiterer ist die Leistung, wenngleich dieser Aspekt bereits bei den früheren Umsetzungen wichtig war. Der Algorithmus benötigt etwa 1,5 ms für die Rekonstruierung des Bildes in 4K auf einer GeForce RTX 2080 Ti. Diese 1,5 ms werden oft als Latenz angenommen, die durch DLSS hinzukommen und einen negativen Einfluss haben.

Allerdings reduziert DLSS 2.0 die Zeit für das Rendering eines Frames – liefert mehr FPS. Gehen wir von 60 FPS ohne DLSS und einer Steigerung auf 100 FPS durch DLSS aus, benötigt die Berechnung eines Frames ohne DLSS etwa 16 ms und mit DLSS 2.0 etwa 10 ms. Darin mit eingerechnet sind die 1,5 ms für die Rekonstruierung des Bildes. Der Overhead von 1,5 ms ist bei einer Auflösung von 4K immer identisch.

NVIDIA liefert die Zeiten für die Rekonstruierung des Bildes auf der verschiedenen Karten mit unterschiedlicher Auflösung. Mehr als 2,5 ms sollen es in keinem Fall sein. Im Vergleich zur Gesamtzeit, die für das Rendering eines Frames aufgewendet wird, benötigt die Rekonstruierung also nur ein Bruchteil. 

Die Verbesserungen in den FPS haben wir uns mit DLSS 2.0 zu zahlreichen Gelegenheiten bereits angeschaut (Control, Mechwarrior 5, Deliver us the Moon und Wolfenstein: Youngblood).

Im Vortrag geht es vor allem darum, zu verstehen, wie DLSS 2.0 die Rekonstruierung vornimmt. Einfach nur ein AI-Upscaling oder einer andere Interpolation (Bicubic Upsampling) zu verwenden, ist für DLSS nicht möglich. ESRGAN ist ein Algorithmus, der schon erste Verbesserungen bietet, noch immer aber nicht das gewünschte Resultat bietet.

Dazu bietet NVIDIA einige Vergleiche. Für einzelne Frames wäre dies vielleicht noch in dieser Form umsetzbar, aufgrund der vielen Änderungen zwischen den Frames und der fehlenden temporalen Stabilität sähe das Ergebnis aber deutlich schlechter aus. So kommt mit DLSS 2.0 ein temporales Feedback zum Einsatz. Dieses wird als Feedback-Schleife genutzt, um die Bildqualität zu verbessern. Vor allem kleine Objekte, die sich in Bewegung befinden, stellten für das DLSS bisher noch Probleme dar. Das temporale Feedback soll dies deutlich verbessern. 

Ein Großteil des Vortrags beschäftigt sich mit den unterschiedlichen Verfahren für eine Interpolation, dem Multi-Frame Super-Resolution, dem Spatial-Temporal Super Sampling und zum Beispiel dem Clamping, welches das Flimmern reduzieren soll.

Für die Entwickler soll die Integration von DLSS 2.0 so einfach wie möglich gestaltet werden. Sie sprechen einfach nur per SDK die NGX-API an. Die eigentlichen Berechnungen mit den niedrig aufgelösten Samples, den Flimmer-Offsets, den Bewegungsvektoren und den weiteren Inputs müssen nicht beachtet werden. Vor der Post Processing Pipeline bekommt der Entwickler bzw. die Engine den Frame zurück und kann noch weitere Prozesse durchführen: Motion Blur, Bloom und einen Tonemapper zum Beispiel. 

Den gesamten Vortrag findet man im folgenden Video: