Die Latenz-Folie vom Igor sagt leider nicht so viel aus ohne die dazugehörigen FPS.
Man könnte ja die DLSS3 Latenzen vergleichen mit pre-rendered frames auf 2 oder triple buffering. Battlefield oder Iracing hat die option.
Für video-playback gibt es eine handvoll Lösungen - nvidia hat dafür die optical flow api rausgebracht. https://developer.nvidia.com/blog/whats-new-in-optical-flow-sdk-3-0/
Für mehr Informationen besuche die Datenschutz-Seite.
hier noch paar andere Frame-berechner. Die unterschiedlichen Verfahren sind mehr oder weniger Echtzeit fähig. Es macht den eindruck als wäre dies auch machbar ohne spezial Rechenwerke. Also entweder Nvidia schlägt uns wieder Ihre Marketingwischiwaschi um die Ohren oder es sind keine eingeschobenen Frames.
Das Frame wird wohl nicht eingeschoben wie beim TV. Diese berechnen den Mittelwert zwischen den zwei Bildern. Die Folie mit den Vektoren suggeriert, dass das Bild extrapoliert wird. Also das Zwischenbild wird geraten, sobald das letzte echte Frame berechnet wurde. Wohl anhand der letzten realen Frames. Um die Verschiebungsvektoren zu berechen brauchts mindestens 2. Wenn noch bisschen gesmooth wird, damit die Änderungen der Vektoren nicht zu gross wird, könnten noch ein 3 oder 4 richtiges Frame in der Berechnung drin sein.
Was genau im Cpu Limit passiert - vorallem bei dieser gepatchten Cyberpunk version - ist mir auch schleierhaft. Zuerst nativ 23FPS und 160ms und dann mit den Optimierungen 100FPS und 55ms. Wie kommen die auf die 55ms, werden da vereinfachte cpu Frames generiert? In diesem Fall müssten auch 4 Bilder eingeschoben werden. Bei einem Film mit bekanntem Frame pacing einfach, jedoch bei Echtzeitberechnung ein Glücksspiel.
Das ganze müsste doch über die Eingabeverzögerung ableitbar sein. Wenn ein Zwischenbild aus den echten Frames davor und danach berechnet wird dann muss die Latenz hoch gehen. Das einzige was denkbar wäre ist, dass das "danach Frame" zuerst nur in der Downsample version berechnet wird, diese Informationen für das Zwischenframe genutzt werden und anschliessend das "danach Frame" fertiggestellt wird.
Für VR wäre mit der Kombination von DLSS3 und Single Pass Stereo auch ein weiterer Rendermodi denkbar. Single Pass Stereo errechnet den Blickpunkt für beide Augen in einem CPU Frame. Das eine Auge wird dann richtig berechnet und das zweite geraten aus den vorhanden Informationen. Man kann die Frames auch jede Runde zwischen den Augen tauschen.
Man könnte ja die DLSS3 Latenzen vergleichen mit pre-rendered frames auf 2 oder triple buffering. Battlefield oder Iracing hat die option.
Für video-playback gibt es eine handvoll Lösungen - nvidia hat dafür die optical flow api rausgebracht. https://developer.nvidia.com/blog/whats-new-in-optical-flow-sdk-3-0/
Eingebundener Inhalt
Youtube
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst:
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.Für mehr Informationen besuche die Datenschutz-Seite.
Das Frame wird wohl nicht eingeschoben wie beim TV. Diese berechnen den Mittelwert zwischen den zwei Bildern. Die Folie mit den Vektoren suggeriert, dass das Bild extrapoliert wird. Also das Zwischenbild wird geraten, sobald das letzte echte Frame berechnet wurde. Wohl anhand der letzten realen Frames. Um die Verschiebungsvektoren zu berechen brauchts mindestens 2. Wenn noch bisschen gesmooth wird, damit die Änderungen der Vektoren nicht zu gross wird, könnten noch ein 3 oder 4 richtiges Frame in der Berechnung drin sein.
Was genau im Cpu Limit passiert - vorallem bei dieser gepatchten Cyberpunk version - ist mir auch schleierhaft. Zuerst nativ 23FPS und 160ms und dann mit den Optimierungen 100FPS und 55ms. Wie kommen die auf die 55ms, werden da vereinfachte cpu Frames generiert? In diesem Fall müssten auch 4 Bilder eingeschoben werden. Bei einem Film mit bekanntem Frame pacing einfach, jedoch bei Echtzeitberechnung ein Glücksspiel.
Das ganze müsste doch über die Eingabeverzögerung ableitbar sein. Wenn ein Zwischenbild aus den echten Frames davor und danach berechnet wird dann muss die Latenz hoch gehen. Das einzige was denkbar wäre ist, dass das "danach Frame" zuerst nur in der Downsample version berechnet wird, diese Informationen für das Zwischenframe genutzt werden und anschliessend das "danach Frame" fertiggestellt wird.
Für VR wäre mit der Kombination von DLSS3 und Single Pass Stereo auch ein weiterer Rendermodi denkbar. Single Pass Stereo errechnet den Blickpunkt für beide Augen in einem CPU Frame. Das eine Auge wird dann richtig berechnet und das zweite geraten aus den vorhanden Informationen. Man kann die Frames auch jede Runde zwischen den Augen tauschen.
Zuletzt bearbeitet:
