DLSS 3 im ersten Praxis-Test: Wie gut ist Nvidias neues Upsampling mit KI-Frameraten-Boost?

[DARPA]

Wenn man FG nicht aktiviert, sondern nur Upsampling (mit den bekannten Qualitätsstufen), ja.

Wobei man schon bei Version 2.4 oder so ist
Deswegen spricht man offiziell nur von DLSS 1 / 2 / 3

 

[Dolomedes]

Ich hab gestern auch das ganze mal in vr probiert, läuft ja an sich super, kann aber nach ejner Zeit mit dlss stehen bleiben, hatte mal ne zeig testest sah super aus so 102fps(average) nativ 4k mit nem 160er fov mehr hab ich noch nicht probiert, Aber es bleibt hier und dam mal stehn, das spiel nach ner zeit, an speicher liegt nich und die gpu auslastung hab ich auch in den griff bekommen ...trotzdem tritt das hier und da auf, givt noch so viel zu testen und irgendwo schmiert man dann doch ne stunde 2 in nem spiel ab.

 

[Jaffech]

Wenn ich das richtig verstanden habe, wird Frame 1 gerendert, dann Frame 2, dann der Frame 1.5 erzeugt.

Führt das dann nicht zu einer erhöhten latenz, da immer erst der nachfolgende frame brechnet werden muss bevor der davorige ausgegeben wird? Inkl Frame 1.5 und unter vernachlässigung von dynamischen Spielinhalten und der Berechnungszeit von Frame 1.5, müsste das dann ja 50% höhere Latenz bedeuten, welche mit 100% höhere Framerate negiert wird?

 

[Olstyle]

@Destroyer0203 ja das führt zu Latenz und das steht so auch im Artikel.
Negiert wird da aber garnichts. Die Latenz kommt auf die bei nativer Framerate drauf. Dafür zwingt NV die Entwickler immer Reflex umzusetzen. Was eigentlich ein unabhängiges Feature ist, aber zumindest dafür sorgt dass nicht noch unnötige Extraverzögerung aus dem Prerendering der Engine kommt.

 

[PCGH_Torsten]

Das ist sogar schon Quadbuffering:

#1: Bild 1, fertig, wird ausgegeben
#2: Bild 2, fertig, wartet
#3: Bild 3 in Arbeit
#4: Bild 1,5 wird gerade interpoliert

Bei der Latenz wirkt sich das aber anders aus, als der Schritt von Double zu Tripple Buffering. Bei einer GPU-Framerate, die halb so hoch wie die Bildwiederholrate des Monitors ist, braucht Triple Buffering gut zwei Refresh-Zyklen, ehe ein Anlass aus dem Gameloop angezeigt wird und dann noch einmal vier, ehe man auch die Reaktion sieht. DLSS 3.0 ist bei der Ausgabe der Reaktion genauso schnell, aber der gesamte Berechnungs-Loop ist um einen Refresh-Zyklus nach vorne verschoben und man reagiert nicht auf einen zwei Zyklen alten Inhalt, sondern auf einen drei Zyklen alten. (Gesamtlatenz von Anlass im Gameloop bis Ausgabe der Reaktion: 7 Zyklen statt 6.) Double Buffering ohne Vsync kommt dagegen im Best Case (= Anlass und Reaktion liegen auf der richtigen Seite der Tearingzone) mit einem Zyklus Vor- und zwei Zyklen Nachlauf aus. (3 insgesamt)

Das alles natürlich unter der perfekt theoretischen Annahme, dass die Tensorcores ihre Arbeit in 0,0 ms erledigen oder zufällig immer rechtzeitig genug vor dem nächsten Refresh damit beginnen können, um noch vor diesem fertig zu werden, und unter der Annahme, dass sie dafür weder Strombudget noch Speichertransferrate zu Lasten der Shader benötigen. In der Praxis ist all das natürlich nicht garantiert, sodass die DLSS-Ausgabe sich bei einigen Frames um einen weiteren Zyklus verlangsamen wird und es werden auch nicht exakt doppelt so viele Fps erreicht, sodass bei gleicher Monitorwiederholrate entweder das Triple-Buffering-System ab und zu mal einen Frame nur einmal anzeigt und dadurch einen Zyklus einspart oder aber das DLSS-3.0-System manchmal drei Refreshzyklen mit einem Render-Frame überbrücken muss.
@PCGH_Phil: Weißt du, ob Nvidia in letzterem Fall zwei Zwischenbilder berechnet oder ob eins wiederholt angezeigt wird? Im Prinzip braucht man dann ja sogar fünf Buffer.

Ich muss meine Einschätzung nochmal korrigieren: Das kürzglich Gesagte gilt nur, wenn man eine 0-Reaktionszeit seitens des Spielers annimmt und der erste Frame einfach schon fertig ist, weil der Redakteur nur den weiteren Verlauf betrachtet. Geht man von einem fortlaufenden Renderloop und einer gewissen Reaktionszeit aus, ändert sich bei Triple-Buffering als Bezugspunkt erstmal wenig – der Input folgt einen Zyklus später auf den Game-Loop (=> Output-Lag knapp vier statt knapp drei Zyklen), aber da die Grafikkarte unter meinen ursprünglichen Annahmen ohnehin einen weiteren Zyklus brauchte, ehe sie die das Bild dazu berechnen konnte, ändert bei der Ausgabe nichts (=> Input-Lag drei statt vier Zyklen).

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.

 

[Olstyle]

Stimmt, Input Lag sind Mausbewegung->USB und DP->Bild. USB -> DP, also das was der PC macht ist eigentlich was Anderes.

 

[WeltbesterGabbyJay]

Ich muss meine Einschätzung nochmal korrigieren: Das kürzglich Gesagte gilt nur, wenn man eine 0-Reaktionszeit seitens des Spielers annimmt und der erste Frame einfach schon fertig ist, weil der Redakteur nur den weiteren Verlauf betrachtet. Geht man von einem fortlaufenden Renderloop und einer gewissen Reaktionszeit aus, ändert sich bei Triple-Buffering als Bezugspunkt erstmal wenig – der Input folgt einen Zyklus später auf den Game-Loop (=> Output-Lag knapp vier statt knapp drei Zyklen), aber da die Grafikkarte unter meinen ursprünglichen Annahmen ohnehin einen weiteren Zyklus brauchte, ehe sie die das Bild dazu berechnen konnte, ändert bei der Ausgabe nichts (=> Input-Lag drei statt vier Zyklen).

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.

Danke für die Erläuterungen, Bruder.
Konntest Du das auch schon im Praxistest bestätigen?

 

[PCGH_Torsten]

Nö. Abgesehen davon, dass das eher Phils Testfachgebiet ist, während ich gerade mit Mainboards zugeschmissen werde, haben wir bislang einfach keine Grafikkarte die Frame Generation beherrscht und mit <<60 Fps nativ in einem DLSS-3.0-unterstützenden Spiel läuft. Die Fühlbarkeit dieser Effekte mit einer RXT 4090 zu beurteilen ist kaum möglich. Zwar kann auch die 120 auf 240 Fps interpolieren, aber wer kann single-frame-Unterschiede bei 120 Fps sauber zuordnen?

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 @PCGH_Dave 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.

 

[WeltbesterGabbyJay]

Abgesehen davon, dass das eher Phils Testfachgebiet ist

Ah? Dann muss ich Euch verwechselt haben, für mich seht Ihr alle so gleich aus! : D

Man darf dann ja gespannt sein.
Ich für meinen Teil habs gerne so Lag-frei wie möglich.

 

[DARPA]

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?

Lag heisst ja übersetzt (zeitliche) Verzögerung.
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!