alalcoolj
Software-Overclocker(in)
[Erklärung] Über Vsync und den Zusammenhang zu input lag und Bildstottern bei 60 Hz und 120/144 Hz
Über Vsync und den Zusammenhang zu input lag und Bildstottern bei 60 Hz und 120/144 Hz
Eine Erklärung von alalcoolj
Inhaltsverzeichnis
Im Netz gibt es eine Vielzahl von Fragen, die sich um tearing, hohen input lag oder ruckelnde Bildwiedergabe bei 3D-Spielen drehen. Vsync hilft erfolgreich gegen tearing, kann aber, je nach Situation, zu reduzierten fps, erhöhtem input lag und Bildstottern führen. Diese Auswirkungen von Vsync scheinen häufig nicht vollständig verstanden. Es lässt sich auch kaum eine umfassende (theoretische) Behandlung dieser Thematik im Netz finden. Dieser Beitrag ist ein Versuch hier etwas mehr Klarheit zu schaffen.
Vsync kann auf verschiedene Weisen implementiert werden. Neben double buffering (DB) und echtem tripple buffering (rTB, für real tripple buffering) kommen häufig sogenannte render ahead queues (cTB=common tripple buffering) zum Einsatz, welche oft auch als tripple buffering bezeichnet werden, da sie drei oder mehr buffer verwenden. cTB kommt als Vsync-Methode häufig bei DirectX-Spielen zum Einsatz. Einige Spiele lassen dem Spieler die Wahl zwischen DB und cTB. Spielt man unter Windows (mit aktiviertem Aero) hingegen im randlosen Fenstermodus, so kommt rTB zum Einsatz, welches auch für den Windows Aero Desktop genutzt wird. rTB kommt außerdem bei OpenGL Spielen zum Einsatz und kann (nur) für diese im Geforce-Treiber auch forciert werden. Doch was unterscheidet diese 3 Methoden im Hinblick auf input lag, Bildstottern und angezeigten fps untereinander und im Vergleich zu abgeschaltetem Vsync? Welchen Vorteil hat man durch 120 Hz / 144 Hz Monitore?
Zunächst betrachten wir die Situation bei einem 60 Hz Monitor. Bei aktiviertem VSync (egal ob mit DB, rTB oder cTB!) kann die Anzeigedauer eines Bildes, die frametime, nur 1/60 s (=1 Monitor refresh a 16,67 ms), 1/30 s (=2 Monitor refreshs), 1/20 s (=3 Monitor refreshs), 1/15 s (=4 Monitor refreshs), etc. betragen. Ansonsten würde man tearing beobachten können, was ja gerade durch VSync verhindert wird. D.h. ein fertig berechnetes Bild wird entweder einmal, zweimal, dreimal usw. angezeigt. Für eine umfassende Einführung der buffering Methoden, insbesondere rTB, s. Triple Buffering: Why We Love It.
2. Fps und Bildstottern
Ohne VSync werden so viele fps berechnet und (zumindest teilweise) angezeigt, wie es die Hardware hergibt. Bei ausreichend hohen fps (es hängt vom Spiel und auch vom Spieler ab, was als ausreichend empfunden wird) kommt ein recht flüssiges Spielgefühl auf. Bei stark schwankenden fps, wie sie in einer Spielszene auftreten können, wenn man z.B. die Spielkamera vom nicht allzu komplexen Himmel auf die Spielwelt schwenkt, ist die Reduzierung der fps spürbar. Das auftretende tearing ist der Hauptgrund, aus dem viele Spieler nicht ohne Vsync spielen möchten.
2.1 Double buffering
Bei Vsync mit DB können maximal 60 fps berechnet werden, da der (einzige) backbuffer dann voll läuft und auf den nächsten Monitor refresh gewartet werden muss bevor weiter gerechnet werden kann. Kann die Hardware permanent mindestens 60 fps berechnen, so hat man ein sehr flüssiges Spielgefühl - alle 16,67 ms bekommt man ein neues vollständiges Bild angezeigt und es gibt keine Schwankungen in den fps oder frametimes. Das Problem bei DB entsteht, sobald die Hardware länger als 16,67 ms zur Berechnung eines Bildes benötigt. Dann läuft das Spiel nur mit 30 fps ab: Da beim Monitor refresh nach 16,67 ms noch kein weiteres fertig berechnetes Bild vorliegt, wird das eben angezeigte Bild erneut angezeigt. Können keine 30 fps erreicht werden, d.h. liegen die frametimes über 33,33 ms, so werden nur noch 20 fps angezeigt, etc. Da das Bild im backbuffer noch fertig berechnet werden muss und dann bis zum nächsten refresh in diesem einzigen backbuffer verbleibt, kann die Grafikhardware bis dahin kein weiteres Bild berechnen - Grafikleistung liegt brach.
2.2 Tripple buffering
Beide Methoden mit 3 buffern (rTB und cTB) verhalten sich bei unter 60 fps gleich. Da nun ein weiterer backbuffer (also insg. 1 frontbuffer und 2 backbuffer) zur Verfügung steht, laufen diese bei unter 60 fps nie voll. Wenn ein backbuffer voll ist, wird einfach im zweiten backbuffer weiter gerechnet. Somit ist es auch möglich z.B. 40 Bilder in einer Sekunde zu berechnen und anzuzeigen. Jetzt aber der wichtigste Punkt: Aufgrund der Synchronisierung mit der Monitorfrequenz sind trotz der 40 fps nur frametimes von exakt 16,67 ms oder 33,33 ms möglich - ein Bild wird entweder einmal oder doppelt angezeigt. Bei 40 fps also folgendermaßen: Bild 1, Bild 1, Bild 2, Bild 3, Bild 3, Bild 4, Bild 5, Bild 5, Bild 6, ... Während man sich womöglich über eine höhere durchschnittliche (!) fps-Anzeige freut als bei double buffering (40 fps vs. 30 fps), hat man aufgrund der schwankenden frametimes ein ruckeliges Spielgefühl. Werden allerdings z.B. 59 fps erreicht, so wird theoretisch innerhalb einer Sekunde nur ein Bild doppelt angezeigt (frametime=33,33 ms) und 58 aufeinanderfolgende Bilder mit einer konstanten frametime von 16,67 ms. Das wirkt schon mal deutlich flüssiger als die schwankenden frametimes bei 40 fps. Es hängt also explizit von der aktuellen framerate ab wie ruckelig die Spielsituation empfunden wird.
Kann die Hardware über 60 fps berechnen, so unterscheiden sich rTB und cTB. Der einfache Unterschied zwischen rTB und cTB ist, dass bei rTB im Gegensatz zu cTB ein voller backbuffer überschrieben werden darf. Das führt dazu, dass bei cTB die backbuffer bei über 60 fps volllaufen und auf den nächsten Monitor refresh gewartet werden muss bevor weiter gerechnet werden kann. Somit hat man bei cTB eine indirekte fps Limitierung auf 60 bzw. auf die Bildwiederholfrequenz des Monitors. Jedes berechnete Bild wird also auch angezeigt: Bild 1, Bild 2, Bild 3, Bild 4, Bild 5, etc. Bei rTB sind auch 1000 fps und mehr möglich (macht mal eine Messung mit Fraps bei einem Spiel im borderless window!) - am Monitor angezeigt werden aber auch nur 60 dieser 1000 berechneten Bilder! Es werden bei beiden Methoden zwar 60 verschiedene Bilder pro Sekunde angezeigt, allerdings wirkt cTB meist flüssiger, da der zeitliche Abstand in dem die angezeigten Bilder gerendert wurden konstant ist, nämlich 16,67 ms. Dies ist bei rTB in der Regel nicht der Fall. Bei 90 fps werden hier z.B. folgende Bilder ausgegeben: Bild 1, Bild 3, Bild 4, Bild 6, Bild 7, Bild 9, Bild 10, Bild 12, Bild 13, etc., was nicht ganz so flüssig wirkt. Bei sehr hohen fps fällt die unregelmäßige Bildausgabe weniger auf – bei einem Vielfachen der Monitorfrequenz ist die Bildausgabe sogar gleichmäßig, z.B. bei 120 fps: Bild 1, Bild 3, Bild 5, Bild 7, etc. Man sieht trotzdem nicht mehr als 60 Bilder pro Sekunde, aber die Bilder sind aktueller als bei 60 fps, d.h. der input lag ist geringer (s. Schaubild). Bei cTB ist durch das Volllaufen der backbuffer (bzw. durch das Verbot einen vollen backbuffer zu überschreiben) der durchschnittliche input lag höher (s.u.) als bei rTB.
3. Input lag
Mit input lag ist die Zeit gemeint, die vergeht bis eine Eingabe des Spielers (z.B. Mausklick) auf dem Monitor sichtbar wird, d.h. ein vollständiges Bild fertig angezeigt wurde, das die neue Information enthält. Ohne Vsync werden aufgrund des tearings ggf. mehrere Teilbilder mit der neuen Information angezeigt bis jede Monitorzeile einmal neu überschrieben wurde.
Input lag aus sonstigen Quellen, z.B. Verzögerung der Eingabegeräte, input lag des Monitors selbst etc., ist nicht Thema dieser Betrachtung und kann als konstante Zeitspanne zum hier definierten input lag hinzu addiert werden. Folgendes Schaubild, welches durch theoretische Überlegungen entstanden ist, veranschaulicht den mittleren input lag der verschiedenen VSync Methoden in Abhängigkeit der fps, die von der Hardware in der betrachteten Spielsituation berechnet werden können.
Man erkennt, dass man natürlich ohne VSync immer den geringsten input lag hat. Interessant ist, dass DB bei bestimmten fps-Werten auch exakt diesen minimalen input lag aufweist, z.B. bei genau 30 fps oder 60 fps. TB hat, entgegen vieler Behauptungen im Netz, je nach fps-Bereich auch häufig einen geringeren input lag als DB. Es ist nicht so, dass der zusätzliche buffer generell für einen höheren input lag sorgt. Bei 55 fps z.B. hat TB einen deutlich geringeren input lag, da bei DB die Grafikkarte sehr lange nichts zu tun hat, da aufgrund des vollen (einzigen) backbuffers kein neues Bild berechnet werden kann. Bei mehr als 60 fps unterscheiden sich dann cTB und rTB. Während der input lag bei cTB bei Überschreitung der 60 fps Marke sogar einen Sprung nach oben macht und dann konstant auf hohem Niveau verbleibt, sinkt er bei cTB kontinuierlich parallel zum Fall ohne VSync. Ab 90 fps ist er dann auch immer geringer als mit DB. Bei cTB liegt der sprunghafte Anstieg bei 60 fps daran, dass dann die beiden backbuffer volllaufen und der ältere (im Gegensatz zu rTB) nicht überschrieben wird und im Mittel eine halbe refresh Zeitspanne gewartet werden muss. Dies ist vermutlich der Grund, warum öfter empfohlen wird einen framelimiter einzusetzen um die fps auf 59 oder 58 zu begrenzen.
4. Vorteile durch ein 144 Hz bzw. 120 Hz Display
Ein 120 Hz Monitor weist viele Vorteile gegenüber einem 60 Hz Display bezüglich tearing, input lag und Bildstottern auf. Die folgenden Ausführungen gelten entsprechend auch für 144 Hz Displays.
Ohne Vsync ist eine tearing-Linie, die entsteht wenn ein fertiges Bild an den Monitor geschickt wird, kürzer auf dem Monitor sichtbar, da der refresh bei dem das tearing auftritt kürzer andauert. Ganz vermieden werden kann tearing aber auch bei 120 Hz oder 144 Hz nicht. Allgemein tritt tearing bei fps sowohl über als auch unter der Bildwiederholfrequenz eines Monitors auf.
Bei Verwendung von Vsync mit double buffering fallen die fps nicht auf 30 sobald man 60 fps unterschreitet, sondern auf 40 fps, da ein Bild dann 3 mal angezeigt wird (3 Refreshzyklen à 1/120 s = 1/40 s). Erst wenn keine 40 fps erreicht werden, fallen die fps auf 30. Entsprechend sorgt dies auch für einen kürzeren input lag (s. Schaubild 120 Hz).
Bei tripple buffering stehen nun auch mehr mögliche frametimes zur Verfügung, so dass das aufgrund schwankender frametimes entehende Bildstottern nicht so ausgeprägt ist wie bei einem 60 Hz Monitor.
Generell ist der input lag auf einem 144 Hz oder 120 Hz Monitor sowohl ohne Vsync als auch mit allen Vsync-Methoden geringer als bei 60 Hz. Auch die Unterschiede der verschiedenen Vsync-Methoden sind bei 120 Hz geringer. Außerdem werden bei über 60 fps auch tatsächlich mehr als 60 verschiedene Bilder dargestellt, was auch für ein flüssigeres Spielgefühl sorgt.
5. Fazit und abschließende Worte
Es lohnt sich sehr wohl sich etwas mit den verschiedenen Möglichkeiten von Vsync auseinanderzusetzen. Ich hoffe diese Ausführungen machen deutlich, dass man nur schwer pauschale Empfehlungen aussprechen kann, welche Spiel- oder Treibereinstellungen das Nonplusultra sind, wenn man möglichst kein tearing haben, keine fps verschenken, den input lag gering halten oder Bildstottern minimieren möchte. Die Antwort hängt wie wir gesehen haben stark von den angestrebten und auch erreichbaren fps sowie dem verwendeten Monitor ab. Oft muss man Kompromisse eingehen. Ein 144 Hz Display macht die Sache allerdings etwas einfacher. Dafür muss man allerdings auch etwas tiefer in die Tasche greifen. Wer keine Kompromisse eingehen möchte, kann zu G-Sync oder FreeSync Monitoren greifen, welche gar kein tearing aufweisen und gleichzeitig Bildstottern und input lag minimieren. Die Hersteller lassen sich dies aber auch gut bezahlen.
Vielen Dank an alle, die bis hierhin durchgehalten haben!.gif "sm_B-) :-)")
Nun bin ich gespannt auf euer Feedback. Decken sich diese (etwas theoretischen) Ausführungen mit euren Erfahrungen in der Spielepraxis? Fandet ihr den Beitrag verständlich und hilfreich? Bei künftigen threads, die sich um fps-Einbrüche, Mikroruckeln und input lag drehen oder generell bei VSync Diskussionen, kann er gerne verlinkt werden.
Gruß
alalcoolj
Ergänzung: PCGH_Phil hat den Thread in seinem post (#8 ) um seine Erfahrungen G-Sync/FreeSync super ergänzt.
Über Vsync und den Zusammenhang zu input lag und Bildstottern bei 60 Hz und 120/144 Hz
Eine Erklärung von alalcoolj
Inhaltsverzeichnis
- 1. Einleitung
- 2. Fps und Bildstottern
- 2.1 Double buffering
- 2.2 Tripple buffering
- 3. Input lag
- 4. Vorteile durch ein 144 Hz bzw. 120 Hz Display
- 5. Fazit und abschließende Worte
Im Netz gibt es eine Vielzahl von Fragen, die sich um tearing, hohen input lag oder ruckelnde Bildwiedergabe bei 3D-Spielen drehen. Vsync hilft erfolgreich gegen tearing, kann aber, je nach Situation, zu reduzierten fps, erhöhtem input lag und Bildstottern führen. Diese Auswirkungen von Vsync scheinen häufig nicht vollständig verstanden. Es lässt sich auch kaum eine umfassende (theoretische) Behandlung dieser Thematik im Netz finden. Dieser Beitrag ist ein Versuch hier etwas mehr Klarheit zu schaffen.
Vsync kann auf verschiedene Weisen implementiert werden. Neben double buffering (DB) und echtem tripple buffering (rTB, für real tripple buffering) kommen häufig sogenannte render ahead queues (cTB=common tripple buffering) zum Einsatz, welche oft auch als tripple buffering bezeichnet werden, da sie drei oder mehr buffer verwenden. cTB kommt als Vsync-Methode häufig bei DirectX-Spielen zum Einsatz. Einige Spiele lassen dem Spieler die Wahl zwischen DB und cTB. Spielt man unter Windows (mit aktiviertem Aero) hingegen im randlosen Fenstermodus, so kommt rTB zum Einsatz, welches auch für den Windows Aero Desktop genutzt wird. rTB kommt außerdem bei OpenGL Spielen zum Einsatz und kann (nur) für diese im Geforce-Treiber auch forciert werden. Doch was unterscheidet diese 3 Methoden im Hinblick auf input lag, Bildstottern und angezeigten fps untereinander und im Vergleich zu abgeschaltetem Vsync? Welchen Vorteil hat man durch 120 Hz / 144 Hz Monitore?
Zunächst betrachten wir die Situation bei einem 60 Hz Monitor. Bei aktiviertem VSync (egal ob mit DB, rTB oder cTB!) kann die Anzeigedauer eines Bildes, die frametime, nur 1/60 s (=1 Monitor refresh a 16,67 ms), 1/30 s (=2 Monitor refreshs), 1/20 s (=3 Monitor refreshs), 1/15 s (=4 Monitor refreshs), etc. betragen. Ansonsten würde man tearing beobachten können, was ja gerade durch VSync verhindert wird. D.h. ein fertig berechnetes Bild wird entweder einmal, zweimal, dreimal usw. angezeigt. Für eine umfassende Einführung der buffering Methoden, insbesondere rTB, s. Triple Buffering: Why We Love It.
2. Fps und Bildstottern
Ohne VSync werden so viele fps berechnet und (zumindest teilweise) angezeigt, wie es die Hardware hergibt. Bei ausreichend hohen fps (es hängt vom Spiel und auch vom Spieler ab, was als ausreichend empfunden wird) kommt ein recht flüssiges Spielgefühl auf. Bei stark schwankenden fps, wie sie in einer Spielszene auftreten können, wenn man z.B. die Spielkamera vom nicht allzu komplexen Himmel auf die Spielwelt schwenkt, ist die Reduzierung der fps spürbar. Das auftretende tearing ist der Hauptgrund, aus dem viele Spieler nicht ohne Vsync spielen möchten.
2.1 Double buffering
Bei Vsync mit DB können maximal 60 fps berechnet werden, da der (einzige) backbuffer dann voll läuft und auf den nächsten Monitor refresh gewartet werden muss bevor weiter gerechnet werden kann. Kann die Hardware permanent mindestens 60 fps berechnen, so hat man ein sehr flüssiges Spielgefühl - alle 16,67 ms bekommt man ein neues vollständiges Bild angezeigt und es gibt keine Schwankungen in den fps oder frametimes. Das Problem bei DB entsteht, sobald die Hardware länger als 16,67 ms zur Berechnung eines Bildes benötigt. Dann läuft das Spiel nur mit 30 fps ab: Da beim Monitor refresh nach 16,67 ms noch kein weiteres fertig berechnetes Bild vorliegt, wird das eben angezeigte Bild erneut angezeigt. Können keine 30 fps erreicht werden, d.h. liegen die frametimes über 33,33 ms, so werden nur noch 20 fps angezeigt, etc. Da das Bild im backbuffer noch fertig berechnet werden muss und dann bis zum nächsten refresh in diesem einzigen backbuffer verbleibt, kann die Grafikhardware bis dahin kein weiteres Bild berechnen - Grafikleistung liegt brach.
2.2 Tripple buffering
Beide Methoden mit 3 buffern (rTB und cTB) verhalten sich bei unter 60 fps gleich. Da nun ein weiterer backbuffer (also insg. 1 frontbuffer und 2 backbuffer) zur Verfügung steht, laufen diese bei unter 60 fps nie voll. Wenn ein backbuffer voll ist, wird einfach im zweiten backbuffer weiter gerechnet. Somit ist es auch möglich z.B. 40 Bilder in einer Sekunde zu berechnen und anzuzeigen. Jetzt aber der wichtigste Punkt: Aufgrund der Synchronisierung mit der Monitorfrequenz sind trotz der 40 fps nur frametimes von exakt 16,67 ms oder 33,33 ms möglich - ein Bild wird entweder einmal oder doppelt angezeigt. Bei 40 fps also folgendermaßen: Bild 1, Bild 1, Bild 2, Bild 3, Bild 3, Bild 4, Bild 5, Bild 5, Bild 6, ... Während man sich womöglich über eine höhere durchschnittliche (!) fps-Anzeige freut als bei double buffering (40 fps vs. 30 fps), hat man aufgrund der schwankenden frametimes ein ruckeliges Spielgefühl. Werden allerdings z.B. 59 fps erreicht, so wird theoretisch innerhalb einer Sekunde nur ein Bild doppelt angezeigt (frametime=33,33 ms) und 58 aufeinanderfolgende Bilder mit einer konstanten frametime von 16,67 ms. Das wirkt schon mal deutlich flüssiger als die schwankenden frametimes bei 40 fps. Es hängt also explizit von der aktuellen framerate ab wie ruckelig die Spielsituation empfunden wird.
Kann die Hardware über 60 fps berechnen, so unterscheiden sich rTB und cTB. Der einfache Unterschied zwischen rTB und cTB ist, dass bei rTB im Gegensatz zu cTB ein voller backbuffer überschrieben werden darf. Das führt dazu, dass bei cTB die backbuffer bei über 60 fps volllaufen und auf den nächsten Monitor refresh gewartet werden muss bevor weiter gerechnet werden kann. Somit hat man bei cTB eine indirekte fps Limitierung auf 60 bzw. auf die Bildwiederholfrequenz des Monitors. Jedes berechnete Bild wird also auch angezeigt: Bild 1, Bild 2, Bild 3, Bild 4, Bild 5, etc. Bei rTB sind auch 1000 fps und mehr möglich (macht mal eine Messung mit Fraps bei einem Spiel im borderless window!) - am Monitor angezeigt werden aber auch nur 60 dieser 1000 berechneten Bilder! Es werden bei beiden Methoden zwar 60 verschiedene Bilder pro Sekunde angezeigt, allerdings wirkt cTB meist flüssiger, da der zeitliche Abstand in dem die angezeigten Bilder gerendert wurden konstant ist, nämlich 16,67 ms. Dies ist bei rTB in der Regel nicht der Fall. Bei 90 fps werden hier z.B. folgende Bilder ausgegeben: Bild 1, Bild 3, Bild 4, Bild 6, Bild 7, Bild 9, Bild 10, Bild 12, Bild 13, etc., was nicht ganz so flüssig wirkt. Bei sehr hohen fps fällt die unregelmäßige Bildausgabe weniger auf – bei einem Vielfachen der Monitorfrequenz ist die Bildausgabe sogar gleichmäßig, z.B. bei 120 fps: Bild 1, Bild 3, Bild 5, Bild 7, etc. Man sieht trotzdem nicht mehr als 60 Bilder pro Sekunde, aber die Bilder sind aktueller als bei 60 fps, d.h. der input lag ist geringer (s. Schaubild). Bei cTB ist durch das Volllaufen der backbuffer (bzw. durch das Verbot einen vollen backbuffer zu überschreiben) der durchschnittliche input lag höher (s.u.) als bei rTB.
3. Input lag
Mit input lag ist die Zeit gemeint, die vergeht bis eine Eingabe des Spielers (z.B. Mausklick) auf dem Monitor sichtbar wird, d.h. ein vollständiges Bild fertig angezeigt wurde, das die neue Information enthält. Ohne Vsync werden aufgrund des tearings ggf. mehrere Teilbilder mit der neuen Information angezeigt bis jede Monitorzeile einmal neu überschrieben wurde.
Input lag aus sonstigen Quellen, z.B. Verzögerung der Eingabegeräte, input lag des Monitors selbst etc., ist nicht Thema dieser Betrachtung und kann als konstante Zeitspanne zum hier definierten input lag hinzu addiert werden. Folgendes Schaubild, welches durch theoretische Überlegungen entstanden ist, veranschaulicht den mittleren input lag der verschiedenen VSync Methoden in Abhängigkeit der fps, die von der Hardware in der betrachteten Spielsituation berechnet werden können.
Man erkennt, dass man natürlich ohne VSync immer den geringsten input lag hat. Interessant ist, dass DB bei bestimmten fps-Werten auch exakt diesen minimalen input lag aufweist, z.B. bei genau 30 fps oder 60 fps. TB hat, entgegen vieler Behauptungen im Netz, je nach fps-Bereich auch häufig einen geringeren input lag als DB. Es ist nicht so, dass der zusätzliche buffer generell für einen höheren input lag sorgt. Bei 55 fps z.B. hat TB einen deutlich geringeren input lag, da bei DB die Grafikkarte sehr lange nichts zu tun hat, da aufgrund des vollen (einzigen) backbuffers kein neues Bild berechnet werden kann. Bei mehr als 60 fps unterscheiden sich dann cTB und rTB. Während der input lag bei cTB bei Überschreitung der 60 fps Marke sogar einen Sprung nach oben macht und dann konstant auf hohem Niveau verbleibt, sinkt er bei cTB kontinuierlich parallel zum Fall ohne VSync. Ab 90 fps ist er dann auch immer geringer als mit DB. Bei cTB liegt der sprunghafte Anstieg bei 60 fps daran, dass dann die beiden backbuffer volllaufen und der ältere (im Gegensatz zu rTB) nicht überschrieben wird und im Mittel eine halbe refresh Zeitspanne gewartet werden muss. Dies ist vermutlich der Grund, warum öfter empfohlen wird einen framelimiter einzusetzen um die fps auf 59 oder 58 zu begrenzen.
4. Vorteile durch ein 144 Hz bzw. 120 Hz Display
Ein 120 Hz Monitor weist viele Vorteile gegenüber einem 60 Hz Display bezüglich tearing, input lag und Bildstottern auf. Die folgenden Ausführungen gelten entsprechend auch für 144 Hz Displays.
Ohne Vsync ist eine tearing-Linie, die entsteht wenn ein fertiges Bild an den Monitor geschickt wird, kürzer auf dem Monitor sichtbar, da der refresh bei dem das tearing auftritt kürzer andauert. Ganz vermieden werden kann tearing aber auch bei 120 Hz oder 144 Hz nicht. Allgemein tritt tearing bei fps sowohl über als auch unter der Bildwiederholfrequenz eines Monitors auf.
Bei Verwendung von Vsync mit double buffering fallen die fps nicht auf 30 sobald man 60 fps unterschreitet, sondern auf 40 fps, da ein Bild dann 3 mal angezeigt wird (3 Refreshzyklen à 1/120 s = 1/40 s). Erst wenn keine 40 fps erreicht werden, fallen die fps auf 30. Entsprechend sorgt dies auch für einen kürzeren input lag (s. Schaubild 120 Hz).
Bei tripple buffering stehen nun auch mehr mögliche frametimes zur Verfügung, so dass das aufgrund schwankender frametimes entehende Bildstottern nicht so ausgeprägt ist wie bei einem 60 Hz Monitor.
Generell ist der input lag auf einem 144 Hz oder 120 Hz Monitor sowohl ohne Vsync als auch mit allen Vsync-Methoden geringer als bei 60 Hz. Auch die Unterschiede der verschiedenen Vsync-Methoden sind bei 120 Hz geringer. Außerdem werden bei über 60 fps auch tatsächlich mehr als 60 verschiedene Bilder dargestellt, was auch für ein flüssigeres Spielgefühl sorgt.
5. Fazit und abschließende Worte
Es lohnt sich sehr wohl sich etwas mit den verschiedenen Möglichkeiten von Vsync auseinanderzusetzen. Ich hoffe diese Ausführungen machen deutlich, dass man nur schwer pauschale Empfehlungen aussprechen kann, welche Spiel- oder Treibereinstellungen das Nonplusultra sind, wenn man möglichst kein tearing haben, keine fps verschenken, den input lag gering halten oder Bildstottern minimieren möchte. Die Antwort hängt wie wir gesehen haben stark von den angestrebten und auch erreichbaren fps sowie dem verwendeten Monitor ab. Oft muss man Kompromisse eingehen. Ein 144 Hz Display macht die Sache allerdings etwas einfacher. Dafür muss man allerdings auch etwas tiefer in die Tasche greifen. Wer keine Kompromisse eingehen möchte, kann zu G-Sync oder FreeSync Monitoren greifen, welche gar kein tearing aufweisen und gleichzeitig Bildstottern und input lag minimieren. Die Hersteller lassen sich dies aber auch gut bezahlen.
Vielen Dank an alle, die bis hierhin durchgehalten haben!
Nun bin ich gespannt auf euer Feedback. Decken sich diese (etwas theoretischen) Ausführungen mit euren Erfahrungen in der Spielepraxis? Fandet ihr den Beitrag verständlich und hilfreich? Bei künftigen threads, die sich um fps-Einbrüche, Mikroruckeln und input lag drehen oder generell bei VSync Diskussionen, kann er gerne verlinkt werden.Gruß
alalcoolj
Ergänzung: PCGH_Phil hat den Thread in seinem post (#8 ) um seine Erfahrungen G-Sync/FreeSync super ergänzt.
Zuletzt bearbeitet:
