nVidias Deep Learning Super Sampling - DLSS 2.x, DLSS 3.x, DLSS 4

[Relex]

Wie kommt man denn überhaupt auf 8 ms?

Bei 60 FPS braucht ein Frame 16,66 ms.
Selbst wenn also der Input in Nullzeit verarbeitet wird, ist der Input frühestens nach 16,6 ms am Display sichtbar. Denn der Input wird von der CPU in der Spiellogik umgesetzt und dann wandert das vorbereitete Frame zur GPU wo es bei 60 FPS nunmal 16 ms rendert.

Dann kommen noch Double oder triple buffer dazu die die Latenz ohne VRR noch weiter erhöhen…
Also die Diskussion hier kapier ich gerade nicht…

[Ex3cut3r]

Spielt natürlich eine Rolle. Entsprechende Spiele, wie Shmups, Hardcore Jump'n'Runs und andere Bullet-Hell Spiele wurden nicht dafür designed mit >= 3 Frames Lag gespielt zu werden.

Heute brauchst du die 3-fache Bildwiederholrate, millionenfach höhere Rechenleistung und spezielle Treiber-Features und bist halt immer noch beim doppelten bis dreifachen Input-Lag im Vergleich zu den 80ern / frühen 90ern.

Von daher finde ich es in dem Kontext "wie wir früher gespielt haben" schon recht witzig, da wir "früher" noch gar nicht wieder erreicht haben. Klar, Leute die noch nie an einem CRT irgendwas gespielt haben und entsprechende Spiele nur aus Emulatoren kennen, wissen das natürlich nicht und darum werden halt 30ms gefeiert.

Ach ja, die „Früher war alles "besser“-Mentalität. Da ist sie wieder. Weißt du was? Wenn für dich damals wirklich alles so großartig war, dann kauf dir doch wieder eine Röhre, spiel deine Klassiker in 480p und genieße die pixelige Klotz-Grafik samt CRT-Artefakten. Wenn dir das so viel Freude bereitet, nur zu.

Können wir dann wieder zurück zum eigentlichen Thema kommen?

[Ganon]

Bei 60 FPS braucht ein Frame 16,66 ms.
[...]
Dann kommen noch Double oder triple buffer dazu die die Latenz ohne VRR noch weiter erhöhen…

Ein CRT zeichnet keine Vollbilder, sondern einzelne Zeilen. Der Input Lag ist dann abhängig davon wo der Strahl gerade ist. Schwankt dann also zwischen 0 und 16 ms, was sich dann auf 8ms mittelt.

Konsolen aus den 80ern / frühen 90ern hatte weder Double noch Triplebuffer. Sie rendern den Frame direkt.

Darum flackern übrigens auch auf dem NES manchmal die Sprites, weil ein NES nur 8 Sprites pro Scanline ansteuern kann und man dann einfach die Sprites abgewechselt hat, damit man sie trotzdem noch sehen kann.

Ach ja, die „Früher war alles "besser“-Mentalität.

Noch einer der übelst hart getriggert wurde. Meine Güte, chillt einfach mal, statt wegen so simpler Aussagen gleich an die Decke zu gehen. :ugly:

[Relex]

Ein CRT zeichnet keine Vollbilder, sondern einzelne Zeilen. Der Input Lag ist dann abhängig davon wo der Strahl gerade ist. Schwankt dann also zwischen 0 und 16 ms, was sich dann auf 8ms mittelt.



Das ist mir schon klar, der Scanout erfolgt zeilenweise. Aber damit du einen Scanout machen kannst muss ja erstmal das fertige Frame vorliegen.

Denn eine GPU rendert das Bild interne nicht zeilenweise sondern baut es über verschiedene Renderpasses auf.

Man muss also alle Renderpasses abwarten, bevor man überhaupt erst den ersten Pixel der ersten Zeile ausgeben kann.

Das heißt man hätte bei 60 FPS minimum die 16,67 ms Renderzeit + den Scanout (der ja dann sehr viel schneller erfolgen kann.


Hmm. Schade dass das hier offtopic ist. Mich interessiert das Thema, aber es hat hier eigentlich überhaupt nichts verloren...

[Ganon]

Aber damit du einen Scanout machen kannst muss ja erstmal das fertige Frame vorliegen.

Die alten Konsolen rendern das Bild aber tatsächlich zeilenweise. Kein Doublebuffer. Die Konsole "steuert" tatsächlich den direkt Strahl des CRT. Es gibt sogar Spiele die während einer Scanline die Auflösung ändern (z.B. um das HUD mit einer höheren Auflösung zu rendern).

Es gibt dann aber, um es vollständig zu halten, die Vblank Phase. Da wo der Strahler von unten nach oben wandert, um das neue Bild zu zeichnen. Dort werden dann in der Regel intensivere CPU Berechnungen gemacht.

Super Mario Kart hat z.B. im Multiplayer über den jeweiligen Screens dickere schwarze Balken, weil dort u.a. der User-Input pro Spieler verarbeitet wird und deswegen keine Pixel gerendert werden (können). Aber das Super Nintendo kann prinzipiell auch zusätzlichen Input Lag haben, je nach Spiel. Ältere Konsolen hängen noch direkter am CRT-Signal.

[Relex]

OK. Ich hab mich mit solchen alten Spielen nie tiefer auseinandergesetzt. Das kann dann wenn ich das richtig verstehe aber wirklich nur für grafisch sehr simple 2D Games funktionieren.

Alleine das Grundkonzept eines im Ansatz "modernen" Renderers würde so ein vorgehen komplett unmöglich machen, da du das Bild während der Ausgabe nicht erst fertig rendern kannst. Es muss halt schon fertig sein, weil die Renderpasses eben nacheinander kommen und aufeinander aufbauen und nicht zeilenweise abgefrühstückt werden können (würde man das versuchen, wäre es wahrscheinlich unendlich langsam, weil du die parallelität der GPU überhaupt nicht nutzen könntest). Wenn du das erste Pixel der ersten Zeile darstellen willst musst du alle Renderpasses durchlaufen haben. Sonst ist die Farbe eben falsch. Man muss die Geometrie Laden, die Texturen, die Shader usw. Aber hatte ich ja schon gesagt.

Das alles fällt halt mit nem 2D game weg. Man braucht keine 3D Modelle und Texturen, keine Shader und kein Filtering. Man hat die Sprites und kann sie direkt in einem Schritt rendern, zeile für zeile.

Der geringe Inputlag ergibt sich dann also prinzipbedingt aus der simplen Technik und bleibt für moderne Spiele damit unerreichbar, da der Renderansatz das überhaupt nicht ermöglicht.

[Tobalt]

Relex du hast insofern Recht, dass aktuelle Enginee ganze Frames buffern, und diese erst dann ausgeben.

Künftig steht dies aber wieder zur Disposition IMO, auch wenn ich damit hier traditionell in der Minderheit bin..

Das temporale Upsampling wie DLSS gehen ja schon einen kleinen Schritt in diese Richtung.. Sie samplen an jedem Zeitpunkt nur einen Teilframe. Damit das ganze dann mit der restlichen Render und Display Kette kompatibel bleibt, wird auf der GPU selbst zum vollständigen Frame interpoliert.

Aber dieser letzte Schritt ist ja eben genau der Displaytechnik geschuldet, die halt ganze Frames will. Wenn man dies jetzt nicht annimmt, dann wäre auch folgendes denkbar:

Zu einem Zeitpunkt wird nur ein kleines Tile oder gar nur einziges Pixel geshadet und dann auch nur dieses ausgegeben. Das macht natürlich nur mit Selbstleuchtern mit sehr hoher Peakhelligkeit sinn. Der Seheindruck eines solchen Displays wäre quasi "Natürlich", weil damit sämtlichen Artefakte von aktuellen Frame basierten Displays ausgeräumt würden.

Leider noch weite Zukunftsmusik. Man braucht völlig asynchrone Engines und Displays. Mal schauen ob es irgendwann etwas in der Richtung gebe wird. Vielleicht an einem Punkt so unsere jetzige Technik eh nicht einsetzbar ist...ZB vollimmersive VR

[Lurtz]

Noch einer der übelst hart getriggert wurde. Meine Güte, chillt einfach mal, statt wegen so simpler Aussagen gleich an die Decke zu gehen. :ugly:
Sagt derjenige, der mit einem Äpfel-Birnen-Vergleich hier reintrollt, nur um dann rumzujammern, dass er "missverstanden" wird :ugly:

[Ganon]

Der geringe Inputlag ergibt sich dann also prinzipbedingt aus der simplen Technik und bleibt für moderne Spiele damit unerreichbar, da der Renderansatz das überhaupt nicht ermöglicht.

Das stimmt natürlich.

Aber die Rendering-Technik alleine ist es ja nicht. Du kannst die Spiele mit 240 fps rendern und dein Input-Lag ist trotzdem Mist und nicht bei ~8ms (Frameraten Entkoppelung, geringere Logik Hz, etc.)

Aber darum gibt es ja nun Dinge wie Reflex. Die Dinge die Reflex so liefert hatten einige Emulatoren schon lange davor ähnlich drinnen. Ähnliches Problem, ähnliche Lösung. Besser wäre es, wenn die Engine es von alleine schon besser machen würde.

Du könntest aber natürlich wieder Spiellogik an die Framerate koppeln und den Input im Mainloop verarbeiten. Das macht dann natürlich woanders Probleme mit komplexeren Lösungen. Technisch spricht aber prinzipiell erst mal nichts dagegen, auch die Rendering Technik nicht. Du könntest auch die Logik-Hz einstellbar machen, aber da die Engines ja heutzutage eher für den 20Hz Multiplayer-Kram optimiert werden, ist das halt oft keine Option.

Sagt derjenige, der mit einem Äpfel-Birnen-Vergleich hier reintrollt, nur um dann rumzujammern, dass er "missverstanden" wird :ugly:

Gejammert hab ich nicht, eigentlich war es nur eine lustige Anekdote. Dass das einige Leute hier hart triggert und sie sofort alle unsinnigen Gegenmaßnahmen hochfahren, war einfach nur ein amüsanter Bonus für den Tag und nicht unbedingt beabsichtigt. :ugly:

[Gast]

Der Input Lag ist dann abhängig davon wo der Strahl gerade ist. Schwankt dann also zwischen 0 und 16 ms, was sich dann auf 8ms mittelt.




Der Lag ist nicht abhängig von 0-16ms sondern (bei 60Hz) immer mindestens 16ms oder bei PAL/50Hz sogar 20ms. Von einer zur nächsten Änderung einer Scanline vergeht immer mindestens diese Zeit. Auch wenn die Scanline in der Mitte 8ms nach der ersten gezeichnet wird, muss ja erst die untere Hälfte des Bildes, und dann wieder die obere Hälfte gezeichnet werden bis sie sich wieder ändern kann. Die Untergrenze für die Latenz ist damit immer eine ganze Frametime.