Reden wir jetzt von frame Interpolation oder frame Generation?
Das erste ist wie beim Fernseher um etwas flüssiger darzustellen was low framerate hat...
Nett um zb 30hz content auf 60hz zu interpolieren.. aber mehr auch nicht..nix anderes wie Fluid Motion um n Video auf n high refresh display zu "glätten"
Das andere erzeugt aktiv frames im spielgeschehen
Für mich klingt das jetzt eher nach ersteren.. was zwar nett ist.. aber nicht so berauschend wie frame Generation
"Frame Generation" ist nur Marketing-Buzzword für Interpolation mit
EYEI!!!. So als hätten alle vorherigen Ansätze strunzdoof gewürfelt. GPUs haben gegenüber Fernsehern zwar den großen Vorteil, dass sie Objektbewegungen nicht allein aus Bildvergleichen rekonstruieren müssen, sondern sie teilweise direkt aus dem Geometrieteil der Engine erhalten, aber am Ende wird dennoch interpoliert, wo Farbklecks A auf halber Strecke zwischen Frame 0 und Frame 1 war.
Da kommt aber optimalerweise dann kein weiterer, zusätzlicher Input-Lag dazu (bis auf die Zeit, die für das Erstellen der KI-Frames benötigt wird). Du brauchst ja trotzdem nur zwei voll berechnete Frames, die zurückgehalten werden müssen - daher kommt der Lag.
Ob du einen, zwei, drei oder dreitausend KI-Frames dazwischen erzeugen lässt, ist im Grunde egal (bis auf deren Berechnungszeit, die aber eben auch deutlich niedriger sein muss, als jene der voll erzeugten Frames, sonst bringt es nichts, dann kann man es gleich bleiben lassen).
EDIT: Könnte allerdings beim Frametime-Pacing etwas weird werden, wenn ein langer (der erste voll berechnete Frame), dann vier sehr kurze (die KI-Frames) und darauf wieder ein langer (der zweite vollberechnete) aufeinander folgen. Ganz unproblematisch ist das also trotzdem nicht.
Gruß,
Phil
Die Generation der KI-Frames beginnt erst, wenn man die beiden Render-Frames hat, also auch deren zeitlichen Abstand kennt. Es sollte also kein großes Problem sein, die Spanne dazwischen gleichmäßig in KI-Schnipsel zu teilen. Der weiße Elefant im Raum ist aber die Frage nach dem Sinn: Während
zusätzliche KI-Frames den Lag nicht beeinflussen, würden KI-Frames statt Render-Frames das sehr wohl machen. Mit ×4 könnte man also echte 60 Fps auf 240 statt auf 120 aufblasen, bei gleichbleibender Latenz. Aber sich 240 statt 120 Fps wünscht, macht das ja meist wegen einer
besseren Latenz und die könnte "DLSS x4.0" nicht bringen. Ebensowenig kann man damit 15 Fps in etwas spielbares verwandeln.
Zumal der im Gegenzug durch Reflex rausgenommene, allgemein vermeidbare Lag eine absolute Größe darstellt. Ich hatte mal überschlagen, dass ein normaler Triple-Buffer-anySync-Render vier Bildausgabezyklen braucht, bis ein Handlungsanlass aus der Engine zu sehen und wenn der Spieler dann reagiert, vergehen noch einmal drei Zyklen, bis man das Ergebnis sieht. Also bei 100 echten Fps hätte man 70 ms Lag insgesamt, davon 30 ms zwischen zwei sichtbaren Ereignissen. Mit 100 Fps, die aus 50 Fps gefaked werden, steht es 10 zu 5 Zyklen respektive 100 und 50 ms. Wenn Reflex im Gegenzug zum Beispiel 20 ms vor dem Rendering einspart, bleiben netto 80 und 30 ms – der volle Round-Trip wird nur 10 ms länger und was man sieht läuft sogar genauso flott ab. Wenn dafür doppelt so GPU-vordernde Grafikeinstellungen laufen (also z.B. "mittlere Details" überhaupt spielbar werden) ein durchaus attraktives Angebot.
Würde man die 100 Fps aber aus 25 echten Frames hochrechnen, um auch mit einer eigentlich um Faktor vier zu schwachen GPU spielen zu können, würden 90 ms vergehen, bis man ein Ereignis aus der Engine überhaupt sieht und dann noch einmal 110 ms, bis die eigene Reaktion darauf in ein Bild einfließt. Aus 200 ms Round-Trip mittels Reflex 180 ms zu machen, wäre ein Tropfen auf den heißen Stein. Statt einer Latenzverschlechterung von 13 Prozent hätte man eine von 100 Prozent.
