DLSS 3.0: Eine Frage der Latenz
Wir schauen uns bei der KI-Upscaling-Technik DLSS 3 an, warum die Latenz so wichtig ist.
In diesem Artikel
DLSS 3.0 - Die Frage der Latenz
Ein weiterer elementarer Bestandteil von DLSS 3.0 ist das ebenfalls von Nvidia stammende Reflex. Dieses Tool dient im Normalfall dazu, die Systemlatenzen auszulesen, also etwa Ihre Latenz von Display, Maus und Grafikkarte zu erfassen und etwa Ihre Reaktionszeit zu messen. Dank ins Spiel integrierter API kann Reflex allerdings auch Einfluss auf die Render-Queue nehmen. Mit diesem Eingriff können Latenzen verringert werden, denn im Normalfall hält die CPU bereits von ihr berechnete Frames zurück, bevor diese an die Grafikkarte zur Weiterverarbeitung gereicht werden. Der Grund dafür ist, dass so die Grafikkarte besser ausgelastet werden kann, da stets ein oder mehrere CPU-Frames in der Hinterhand gehalten werden, die GPU somit auch gefüttert werden kann, wenn es bei der CPU, dem Streaming oder dem Nachladen hängt. Diese zurückgehaltenen Frames erhöhen allerdings auch den Input-Lag, da diese Frames bereits so weit berechnet sind, dass ihre aktuelle Eingabe etwa an der Maus nicht mehr berücksichtigt werden kann. Dies ist natürlich insbesondere in schnellen Shootern unerwünscht - und in diesem Fall hilft Reflex ab. Oder eine andere, zumeist ins Spiel integrierte Option, die etwa lautet "Mauslatenz verbessern", oder "Verringerte Input-Latenz" oder "Future Frame Rendering". Alle diese Techniken machen im Grunde das Gleiche: Sie weisen die CPU an, jeden Frame auf sofortigem Wege zur GPU zu senden, um schnellstmöglich auf neue Inputs des Spielers reagieren zu können.
Die Implementierung von Reflex ist für DLSS 3.0 wichtig, da es gegenüber nativem Rendering (oder auch gegenüber DLSS 2.x, FSR 2.x und XeSS) einen zusätzlichen Frame zurückbehält, um von diesem die KI-generierten Frames abzuleiten. Mit DLSS 3.0 würde also eine zusätzliche, für nicht wenige Spieler wohl merkliche Latenz entstehen, wenn Reflex nicht zum Einsatz käme. Mit DLSS 3.0 samt Reflex ist die Eingabelatenzen in etwa vergleichbar mit dem Spiel bei nativer Auflösung und gleicher Frame-Berechnungszeit - aber dies ist ein weiterer Punkt: Wie wohl alle technisch zumindest etwas versierten Spieler wissen, hat die Berechnungszeit eines Frames ebenfalls Auswirkungen auf die Eingabelatenz - der einfachste Fall ist die Bildrate. Ein Spiel mit 30 Fps fühlt sich weniger flüssig an als ein Spiel mit 60 Fps. Das liegt indes nicht direkt an der durchschnittlichen Bildrate, sondern an der Bildberechnungszeit. Während ein Bild berechnet wird, kann das Spiel nicht auf eine Eingabe reagieren, dies geschieht erst beim nächsten Frame, der darauf von der CPU bereitgestellt und darauf zu GPU gesandt wird. Dieser, spezifisch durch die Bildberechnungszeit ausgelöste Lag liegt bei 30 Fps bei 33 ms, bei 60 bei 16,7. Doch in den seltensten Fällen (oder bei streng via Framelimit abgeriegelten Fps) sind die Berechnungszeiten von mehreren aufeinanderfolgenden Frames gleich. Diese Unterschiede bei den Bildberechnungszeiten sind etwa an den Frametimes ersichtlich. Und ja, Sie können die KI-Frames von DLSS 3.0 tatsächlich an den Frametimes erkennen - und Sie können sie auch spüren. Und dieses Problem kann auch DLSS 3.0 samt Reflex nicht vollständig lösen. Doch der Reihe nach.
DLSS 3.0 und die Problematik zu hoher Leistung und fehlenden Tools
Nvidia stellt uns mit DLSS 3.0, der RTX 4090 und den mit dieser High-End-Grafikkarte erreichbaren, sehr hohen Bildraten sowie der Art und Weise des Launches vor ein gewisses Problem. An erster Stelle sind die Spiele, die uns als Anschauungsmaterial dienen sollen, zum aktuellen Zeitpunkt noch sehr unfertig - sprich: Viele Features, darunter prominent Raytracing, fehlen in den aktuellen DLSS-3.0-Titeln oder sind nur teilweise implementiert. Darunter fällt etwa die neue, für RTX-40er-GPUs ausgelegte Raytracing-Stufe "Overdrive" in Cyberpunk 2077, das Raytracing des noch kommenden Grafikkrachers Plague Tale Requiem und das Raytracing in Microsofts Flight Simulator. Wir können DLSS 3.0 und die RTX 4090 also gar nicht richtig auslasten, aktuell nur eingeschränkt betrachten. Viele der Test-Spiele sind zudem verbuggt, die Cyberpunk-Version mit DLSS 3.0 stürzt etwa mit großer Vorliebe ab, in Plague Tale Requiem ist abseits des fehlenden Raytracing obendrein der Motion Blur in Kombination mit DLSS 3.0 fehlerhaft, laut Nvidia funktionieren außerdem typische Performance-Overlays mit DLSS 3.0 beziehungsweise der Frame Generation nicht korrekt.
Wir können anhand vielfältiger Probemessungen und Vergleichen allerdings festhalten, dass die Performance-Daten beziehungsweise Frametimes, die unser bevorzugtes Tool CapFrameX ausgibt, korrekt sind. Diese stimmen mit den Werten, die Nvidias Frameview (unsere Version ist 1.4.8127) ausgibt, überein. Eine gewisse Abweichung gibt es allerdings bei der Approximation der GPU-Latenzen. Diese wird von Nvidias Frameview laut Aussage von Nvidia "auf andere Art und Weise" interpretiert - sowohl Frameview als auch CapFrameX basieren auf Presentmon, einem Open-Source-Tool, das neben Bildberechnungszeiten, also den Frametimes, den daraus abgeleiteten Fps und P1-Perzentilen eine Vielzahl weiterer Metriken zur Verfügung stellt, darunter auch eine Annäherung, beziehungsweise Approximation der Eingabelatenz, die sich aus folgenden Daten ableiten lässt:
msInputLatency = msBetweenPresents + msUntilDisplayed - previous(msInPresentAPI)
Nvidias Frameview ermittelt die Latenz nach einer anderen Methode - welche genau, das bleibt selbst auf spezifische Nachfrage Nvidias Geheimnis. Wir können also nicht nachvollziehen, wie Nvidias Frameview die Latenzen (näherungsweise) ermittelt. Und wir können zum aktuellen Zeitpunkt auch nicht nachvollziehen, ob diese Daten wirklich korrekt sind - wir gehen selbstverständlich davon aus, doch ist eine nähere Überprüfung sinnvoll, auch um die Methodik besser nachvollziehen zu können. Dies wird weitere, aufwendige Tests erfordern. Bestätigen können wir lediglich die Bildraten beziehungsweise Frametimes. Die Daten für die (ebenfalls geschätzte, approximierte) GPU-Leistungsaufnahme sowie die (geschätzte) GPU-Latenz können wir zum aktuellen Zeitpunkt nicht validieren, dies müssen wir zu einem späteren Zeitpunkt mit weiteren Tests und tatsächlichen, physischen Messungen am Display sowie an der Steckdose verifizieren.
Eine weitere Problemstelle bei der Begutachtung von DLSS 3.0 ist die hohe Leistung der RTX 4090 und der (noch) fehlende Support von entsprechenden (Raytracing-)Grafikeinstellungen in den Test-Spielen. Wir können die RTX 4090 nicht auf ein Bildraten-Level drücken, bei dem sich die Qualität der generierten Frames gut beurteilen ließe. Einzelne Bilder beziehungsweise Frames sind nur so kurz auf dem Bildschirm zu sehen, dass man schwerlich Fehler erkennen würde, selbst wenn diese grober Natur wären. Tatsächlich könnte Nvidia bei extrem hohen, dreistelligen Bildraten wohl alles Mögliche einblenden, ohne dass dies bewusst wahrgenommen würde, selbst einfache, schwarze Bilder. Sie kennen vielleicht den Begriff Black Frame Insertion oder Backlight Strobing, das einige Gaming-Monitore anbieten, um das Bild schärfer wirken zu lassen. Kinofilme sowie viele TVs nutzen eine ähnliche Technologie - ohne, dass Sie die eingefügten, schwarzen Bilder bewusst bemerken würden. Und dies bei einer zum Teil deutlich niedrigeren Bildrate. DLSS 3.0 und die durch Nvidias KI erstellten Frames zu beurteilen, ist am "Lebendbild" daher extrem schwierig. Die Bildraten liegen mit DLSS und ohne Frame Generation oft schon jenseits 100 Fps - und mit Frame Generation häufig um 130 bis über 150. Die Qualität eines so kurz eingeblendeten Frames zu beurteilen, ist nahezu unmöglich. Und doch wirkt das Bild mit Frame Generation unruhiger.
Letzteres liegt allerdings auch daran, dass DLSS 3.0 mit Framegeneration aktuell mit VSync sowie Bildratenbegrenzern inkompatibel ist - es tritt also neben potenziellen Artefakten außerdem Tearing auf, was die Beurteilung nochmals erschwert. Obwohl wir bereits einen 4K-Bildschirm mit 144 Hz sowie Gsync Compatible nutzen. Sie können allerdings beim Einsatz von DLSS 3.0 - oft aus den Augenwinkeln - bei Bewegung andere, oft linienförmige Artefakte erspähen, die zumeist aufzutreten scheinen, wenn das betreffende Objekt zuvor verdeckt wurde. Wie diese rote Leuchtreklame zuvor von der Palme - das Leuchten überträgt sich überdies tatsächlich vom Hintergrund auf den Baumstamm im Vordergrund. Ein weiteres Element, das auch auf Bildern gut Artefakte erkennen lässt, ist das gelbe Quest-Icon, sobald die Kamera bewegt wird. Es sind außerdem häufig Verzerrungen des Bildes zu erkennen, einige Elemente scheinen sich in Bewegung zu "verschieben".
Doch die Auswirkungen sind sehr subtil und es ist ausgesprochen schwierig, genau zu beurteilen, wie stark die generierten Frames eigentlich das Bewegtbild beeinflussen - und noch schwieriger, dies in Bildern oder Text zu kommunizieren. Wenn das eigene Auge nicht zweifelsfrei in der Lage ist, die Unterschiede zwischen tatsächlich berechnetem und generiertem Frame zu beurteilen, benötigen wir ein besseres Auge. Beziehungsweise eine schneller reagierende Linse - beispielsweise die einer Kamera mit extrem niedriger Verschlusszeit. Anders ausgedrückt, eine High-Speed-Kamera. Lassen Sie uns also einmal mittels Kamera-Objektiv begutachten, wie sauber Nvidias KI-Frames tatsächlich ausfallen. Beachten Sie, dass wir den Nebeneffekt des Tearings nicht vermeiden können, da DLSS 3.0 aktuell inkompatibel mit VSync ist - und Tearing trotz Hochfrequenz-Display auftritt. Besonders stark ohne Frame Generation, da die Bildraten niedriger sind, der Tear also eine längere Zeit auf dem Bildschirm sichtbar bleibt. Wirklich isoliert lassen sich die generierten Frames aktuell nicht betrachten.
In unserem Fall die Zeit zwischen Eingabe und Verarbeitung+Ausgabe.
Am Ende ist aber wie so vieles alles nur ne Definitionsfrage.
Und ein Danke für die interessanten Gedanken!
Man darf dann ja gespannt sein.
Ich für meinen Teil habs gerne so Lag-frei wie möglich.
Wenn erstmal die 4060 da ist un beweisen kann, dass mit FG Cyberpunk 2077 in UHD gut spielbar darstellen kann (oder eben nicht), dann wissen wir hoffentlich mehr. Oder vielleicht kann [Ins Forum, um diesen Inhalt zu sehen] mal tief im Prozessor-Archiv wühlen. Aus der Hüfte geschossen würde ich sagen, dass Frame Generation eigentlich bei CPU-Limitierung genauso gut oder schlecht funktioniert, wie im CPU-Limit und ich glaube CPUs, die Cyberpunk mit 20-30 Fps darstellen, gibt es durchaus.
Bei Double-Buffering dagegen verdoppelt sich der Input-Lag realistischerweise um einen Frame = zwei Zyklen, denn man kann unmöglich während der Anzeige eines Bilds so schnell reagieren, dass die Eingabe schon im folgenden, bereits in Berechnung befindlichen Bild berücksichtigt wird. Und für die Berechnung des ersten Bildes sollte man fairerweise auch zwei Zyklen statt einem einplanen.
Bei DLSS 3.0 hat die Berücksichtigung der Reaktionszeit ähnlich drastische Auswirkungen wie bei Double Buffering: Da die Ausgabe des ersten Frames verzögert erfolgt und wir keine Zauberer sind, kann die Reaktion des Spielers nicht mehr rechtzeitig für den übernächsten Frame erfolgen, sondern erst für den über-übernächsten. Das heißt Frame Generation erzeugt gegenüber Triple-Bffering nicht nur einen weiteren Zyklen mehr Output-Lag, sondern zusätzliche zwei Zyklen Input-Lag gegenüber meiner ursprünglichen Schätzung und somit auch gegenüber Triple-Buffering. Das ist genauso mieß wie der Worst-Case bei Double-Buffering mit einem Drittel der (interpolierten) Framerate. Dazu verschlimmert sich auch noch die Zeit, bis man überhaupt reagieren kann, gegenüber Triple-Buffering genauso stark, wie vom Double-Buffer-Best-Case zu Triple-Buffering.
Im Anhang habe ich das mal mit den benötigten Puffern in der GPU darzustellen versucht.
Anmerkung:
Die Begriffswahl ist dem gängigen Gebrauch angepasst, der aber irgendwie reichlich bescheuert ist. Warum nutzen wir eigentlich "Input-Lag" für den Zeitraum von einer Spielereingabe (z.B. Mausbewegung) bis zu deren Darstellung, obwohl es sich um das Warten auf eine Ausgabe handelt? Der oben beschrieben Output-Lag wiederum gibt die Zeit an, bis der Spieler endlich eine Eingabe auf ein Ingame-Ereignis tätigt.
Konntest Du das auch schon im Praxistest bestätigen?