News Geforce RTX 4060 in Cyberpunk 2077: Spielbar oder nicht?

[empy]

Also wird die Latenz um ca. 50% erhöht wenn Framegeneration eingeschaltet ist?

Das kommt drauf an, wie lange die FG dauert. Wenn die FG keine Zeit bräuchte, sollte es ein halber Frame sein. Man könnte zwar den generierten und den echten Frame quasi zeitgleich anzeigen, sobald der generierte Frame fertig berechnet ist, aber dadurch gewinnt man ja nichts, da könnte man ja dann auch gleich den berechneten Frame anzeigen. Also muss man den echten Frame zeitlich in die Mitte von zwei künstlichen Frames schieben. Also ich würde mal sagen ein halber Frame plus die Zeit, die die FG braucht. Also ja, die Latenz, die aus der Zeit zwischen zwei Frames entsteht, erhöht sich um etwas mehr als 50%.

Allerdings sollte man das ganze auch nicht überkritisch sehen, es ist oft üblich, dass standardmäßig Frames von der CPU vorberechnet werden, damit man die GPU sicher auslasten kann, das dürfte mitunter sein, was Reflex und Hypr-Rx ausschalten. Die Latenz, bis diese schon feststehenden Szenen gerendert und angezeigt werden, kommt also auch oft schon dazu und zur endgültigen Latenz von Eingabe bis Ausgabe gehört ja noch mal einiges mehr. In der Gesamtrechnung sorgt der halbe Frame dann schon für deutlich weniger als 50% mehr Latenz.

 

[Olstyle]

Allerdings sollte man das ganze auch nicht überkritisch sehen, es ist oft üblich, dass standardmäßig Frames von der CPU vorberechnet werden, damit man die GPU sicher auslasten kann, das dürfte mitunter sein, was Reflex und Hypr-Rx ausschalten.

Genau das tut Reflex.
Und genau deswegen finde ich Reflex auch nicht uneingeschränkt positiv. In A Plague Tale Requiem hat es sich deutlich ruckeliger angefühlt (im Grunde auch zu erwarten, war nämlich im CPU Limit), in Cyberpunk bei sparsameren Settings auch etwas schlechter.
Deshalb verstehe ich auch nicht warum DLSS3-FG im CPU-Limit toll sein soll. Das erzwingt ja gerade Reflex in einer solchen Situation, was die Frametimes total killen dürfte. Ohne dazu fähige Karte kann ich aber nur mutmaßen.

 

[empy]

Genau das tut Reflex.
Und genau deswegen finde ich Reflex auch nicht uneingeschränkt positiv. In A Plague Tale Requiem hat es sich deutlich ruckeliger angefühlt (im Grunde auch zu erwarten, war nämlich im CPU Limit)

Im CPU-Limit dürfte es doch eigentlich keine Rolle spielen, weil es ja eh keine von der CPU vorberechneten Frames gibt, weil die Grafikkarte die schnell genug abfrühstückt. Passieren da nicht noch andere Sachen?

Deshalb verstehe ich auch nicht warum DLSS3-FG im CPU-Limit toll sein soll. Das erzwingt ja gerade Reflex in einer solchen Situation, was die Frametimes total killen dürfte. Ohne dazu fähige Karte kann ich aber nur mutmaßen.

Kommt wohl drauf an, was man spielt. Das Bild dürfte flüssiger werden, aber die Latenz steigt halt. Wenn es um Reaktionszeit geht, ist FG bei eh schon niedrigen Bildraten dann natürlich Gift.

 

[Olstyle]

Im CPU-Limit dürfte es doch eigentlich keine Rolle spielen, weil es ja eh keine von der CPU vorberechneten Frames gibt, weil die Grafikkarte die schnell genug abfrühstückt. Passieren da nicht noch andere Sachen?

Die Frametimes werden sauberer wenn man einen kleinen Puffer an "Reservdaten" hat um die Bilder in weniger krassen Sprüngen anzeigen zu müssen.
Reflex deaktiviert diesen Puffer und nennt es ein Feature.

 

[empy]

Die Frametimes werden sauberer wenn man einen kleinen Puffer an "Reservdaten" hat um die Bilder in weniger krassen Sprüngen anzeigen zu müssen.

Aber wo sollen die herkommen, wenn die CPU hinterherhechelt? Da gibt es nur eine Option die Frametimes sauberer zu bekommen: Die Framerate senken, so dass es weniger Ausreißer gibt. Gibt auch Spiele, die so eine Glättung anbieten und dann versuchen, die Framerate dynamisch zu limitieren. Aber keine Ahnung, ob und wie gut das funktioniert.

 

[Olstyle]

Aber wo sollen die herkommen, wenn die CPU hinterherhechelt? Da gibt es nur eine Option die Frametimes sauberer zu bekommen: Die Framerate senken, so dass es weniger Ausreißer gibt. Gibt auch Spiele, die so eine Glättung anbieten und dann versuchen, die Framerate dynamisch zu limitieren. Aber keine Ahnung, ob und wie gut das funktioniert.

Siehe diese Zusammenfassung:

Eingebundener Inhalt

Reddit

www.reddit.com/r/nvidia/comments/821n66/_/dv6xcou

An dieser Stelle findest du externe Inhalte von Reddit. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden 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.

Gerade wenn die CPU hechelt und stolpert macht es Sinn dass die GPU diesem Stolpern nicht 1:1 folg.

 

[empy]

Gerade wenn die CPU hechelt und stolpert macht es Sinn dass die GPU diesem Stolpern nicht 1:1 folg.

Das widerspricht meiner Aussage nicht wirklich. Wenn die CPU zu langsam ist, kann sie keinen Puffer aufbauen, weil die Grafikkarte jeden Frame direkt wegrendern kann. Eigentlich ist das einzige Szenario, wenn CPU- und GPU-Limit sich abwechseln. Ansonsten kann das eigentlich nichts bringen. Wenn die GPU immer limitiert, hat die CPU ab der "Abnahme" des aktuellen Frames durch die Grafikkarte genug Zeit, einen neuen Frame zu berechnen, bis die GPU wieder einen braucht, wenn die CPU immer limitiert, kann die Grafikkarte immer direkt losrendern, sobald die CPU einen Frame fertighat. Und die einzige Möglichkeit, dafür zu sorgen, dass die GPU der CPU dann nicht folgt, ist es, die GPU länger als nötig warten zu lassen, also die Framerate zu senken. Wo ist da mein Denkfehler? Ist es so häufig, dass sich die Limits durch andere Prozesse abwechseln?

 

[Olstyle]

Das widerspricht meiner Aussage nicht wirklich. Wenn die CPU zu langsam ist, kann sie keinen Puffer aufbauen, weil die Grafikkarte jeden Frame direkt wegrendern kann. Eigentlich ist das einzige Szenario, wenn CPU- und GPU-Limit sich abwechseln. Ansonsten kann das eigentlich nichts bringen. Wenn die GPU immer limitiert, hat die CPU ab der "Abnahme" des aktuellen Frames durch die Grafikkarte genug Zeit, einen neuen Frame zu berechnen, bis die GPU wieder einen braucht, wenn die CPU immer limitiert, kann die Grafikkarte immer direkt losrendern, sobald die CPU einen Frame fertighat. Und die einzige Möglichkeit, dafür zu sorgen, dass die GPU der CPU dann nicht folgt, ist es, die GPU länger als nötig warten zu lassen, also die Framerate zu senken. Wo ist da mein Denkfehler? Ist es so häufig, dass sich die Limits durch andere Prozesse abwechseln?

In meinem konkreten Beispiel A Plague Tale könnten sich beide Limits tatsächlich abgewechselt haben. Je nach dem wie Physik und Co umgesetzt sind kann es auch sein dass die CPU nur alle X Frames deutlich mehr zu tun hat, dann würde bei vorhandenem Buffer die GPU eben den CPU-Vorsprung kurz Abschmelzen, aber nicht dauerhaft aufholen. Ohne Buffer geht es da dann ins Bodenlose.

 

[empy]

In meinem konkreten Beispiel A Plague Tale könnten sich beide Limits tatsächlich abgewechselt haben. Je nach dem wie Physik und Co umgesetzt sind kann es auch sein dass die CPU nur alle X Frames deutlich mehr zu tun hat, dann würde bei vorhandenem Buffer die GPU eben den CPU-Vorsprung kurz Abschmelzen, aber nicht dauerhaft aufholen. Ohne Buffer geht es da dann ins Bodenlose.

Ja, so was könnte sein, wäre aber schon sehr unelegant gelöst.