VSync, FreeSync, FastSync, CPU/GPU Sync, Engine-Lag, Reaktionszeit, …

​

Frage an einen Hobby-CS:GO-Spieler: »Aktivierst du eigentlich VSync?« – »#NeverSync!«​

Bei vermutlich keiner anderen Grafikoption gibt es so viele Streitigkeiten und Fehlinformationen. Diesbezüglich sind in letzter Zeit frische Varianten und überzeugende Alternativen aufgetaucht. Doch wozu braucht man das überhaupt alles und wie funktioniert es? Wo entsteht Input-Lag und welche Option passt am besten zu welchen Anforderungen? Genau hierüber soll es in den nächsten Abschnitten möglichst detailliert und bebildert gehen.


Inhaltsverzeichnis:

• Warum VSync?
• VSync – Erster Ansatz
• VSync – Die Swap Chain
• Adaptive / Dynamic VSync – Der beste Kompromiss?
• CPU/GPU Synchronisation – Hilfe meine Engine laggt!
• Enhanced Sync und FastSync – Die alten Neuankömmlinge
• Reaktionszeit vs Display-Lag – Die Probleme mit Monitoren
• G-Sync und FreeSync – Alle (?) Fehler an der Ursache beheben
• Lag – Der ultimative Praxistest (samt Fenstermodus und Capping)
• Übersicht und Zusammenfassung – Manche nennen es auch TL;DR

Warum VSync?

»Na wegen Tearing!« dürfte sich der ein oder andere schon denken. Dies bedeutet, dass das Bild förmlich »zerreist«, da mehrere Stücke verschiedener Frames innerhalb eines Monitor-Refresh-Zyklus gezeichnet werden.

Ohne VSync treten hier an vier Stellen des Bildes »Risse« auf (nachgestellte Szene).​

»Doch wieso entsteht dies überhaupt erst, wer zerschnippelt da unsere Bildchen?« ist eine sehr gute Frage. Hierzu sollten wir uns zunächst einmal etwas vereinfacht ansehen wie GPU und Display zusammenarbeiten – oder eher wie sie dies nicht tun. Sei der Puffer im Videospeicher in zwei Stücke aufgeteilt, so nennen wir einen den Front- und den anderen den Backbuffer. Im vorderen wird das Bild für den Monitor gelesen, dies geschieht Zeile für Zeile (in der Animation [noch nicht hinschauen] durch den Zeiger dargestellt) und im hinteren kann die Grafikkarte das nächste Bild berechnen. Doch die beiden haben keine feste Position, vielmehr wird durch Adressumbenennungen aufs Neue festgelegt wer wer ist (unten [immer noch nicht ansehen!] zeigt der Pointer immer auf den Frontbuffer). Dieses »Swappen« findet ohne VSync jedoch sofort statt, also wenn die GPU einen Frame vollständig berechnet hat, sodass sie direkt an einem neuen Bild weiterrechnen kann. Dies hat jetzt aber zur Folge, dass der Bildschirm mitten während der Darstellung einen neuen, anderen Frame erhält und dieser gegebenenfalls völlig unterschiedlich zum vorherigen aussehen kann. Diesen harten Übergang nimmt man letztlich als Screen-Tearing war.

Links der Monitor, rechts die beiden Buffer im VRAM (Frontbuffer markiert).​

Man kann diese Artefakte auch nicht eliminieren, wenn man die Grafikkarte mit einem FPS-Limit drosselt und nun nicht immer direkt die Puffer umbenannt werden. Denn selbst wenn sie genauso schnell wie euer Display operiert weiß die GPU nicht wann ein Refresh beendet ist und ihr erhaltet jeweils einen unschönen Riss. Diese sind nun vermutlich sogar noch hässlicher als vorher, da sie immer an ungefähr der gleichen Stelle auftauchen werden.

Erst wenn die Frames pro Sekunde unter die Bildschirmfrequenz fallen wird es Momente ohne Zerreisen geben, einfach dadurch, dass ein Frame jetzt länger gezeigt wird als der Monitor für einen Refresh benötigt. Da nun pro Zeitintervall deutlich weniger unterschiedliche Bilder angezeigt werden, sinkt zudem die Gesamtzahl der Darstellungsfehler. Das trägt natürlich nicht gerade zu flüssigem Spielen bei.

Achtet vielleicht zuerst nur auf eine Figur, die Hintergrundfarbe zeigt je einen eindeutigen Frame des Disco-Simulators an. Die FPS sind links identisch zum Hertzwert des Displays und niedriger auf der rechten Seite.​

Ohne VSync erhofft man sich das direkteste Spielgefühl, also wie sieht es jetzt mit der Latenz aus? Da das Bild sofort den hinteren Puffer »verlässt«, altert es bei der GPU nur um seine Frametime, also die Zeit, welche für das Rendern benötigt wird. Bei 50 fps mit äquidistanten Bildern hat jedes eine Berechnungsdauer von einer fünfzigstel Sekunde, also 20 ms. In der Realität dauern jedoch keine zwei Frames gleich lange, weshalb man oftmals statt den FPS (von zum Beispiel FRAPS nur über den Durchschnitt mehrerer Frames repräsentativ) eben jene Frametimes (pro Bild ein Wert) bevorzugt betrachten will, um damit einschätzen zu können, ob bestimmte Hardware zufriedenstellend konsistent arbeitet. Letztlich kann man diese Varianz aber kaum beeinflussen. Als Alternative reduzieren manche E-Sportler einfach die Auflösung oder den Detailgrad des Spiels, um so letztlich mehr Bilder herausquetschen zu können, was wiederum die Frametimes – also die Verzögerung – im Generellen verringert.

Allerdings spielt hier auch der Monitor eine entscheidende Rolle. Ein Bildschirm mit 50 Hz erneuert einen Pixel nur jeweils alle 20 ms, also kann ein Frame nochmals rund 20ms altern, bis er überzeichnet wird. Denn selbst bei Frametimes von einer Millisekunde werden die nächsten Bildschnippsel erst an 19 andere Positionen des Displays platziert. Diese sind dann bei erscheinen natürlich brandneu, durch die langsamen 50 Hz dafür weniger groß präsent.

Der Monitor links ist doppelt so schnell wie der andere, somit bleiben rechts die älteren Frames zweimal länger zu sehen und man muss doppelt so lange auf neue Informationen in diesem Bildbereich warten.​

VSync

Damit die (vertikale) Bildsynchronisation überhaupt klappen kann, darf die Grafikkarte nie schneller arbeiten als das Display. Zudem muss sie jetzt mit dem Buffer-Swap warten, bis der vordere Puffer komplett gelesen wurde. Ist die GPU also potent genug, berechnet sie den folgenden Frame im Backbuffer und kann dann Energie sparen solange der Bildschirm für den nächsten Refresh noch nicht bereit ist. Nun wird getauscht und der Grafikprozessor kann den »neuen« Backbuffer bearbeiten. Somit wird Tearing komplett beseitigt und man hat ein geschmeidigeres Erlebnis. Darüber hinaus wird jeder gerenderte Pixel auch angezeigt und die Grafikkarte haut nicht mehr unkontrolliert ihre astronomisch hohen FPS-Werte raus.

Andererseits, was passiert denn wenn sie bei anspruchsvollen Titeln in UHD und maximalen Details mal nicht mithalten kann? Dann sieht es mit VSync nämlich nicht mehr so rosig aus. Sollte der Monitor mit einem Darstellungszyklus durch sein, der Backbuffer aber noch nicht fertig gefüllt sein, so wird (um Bildfehler zu verhindern) der GPU ein weiterer Zeitschlitz gegeben und einfach dasselbe Bild ein weiteres Mal dargestellt. Hierdurch verdoppelt sich die Frametime (und der Lag) direkt, selbst wenn die Grafikeinheit nur eine Millisekunde mehr gebraucht hätte. Zudem muss sie die restliche Zeit des Refresh-Zyklus abwarten und kann nicht einfach das nächste (anspruchsvolle) Bild »vorbereiten«. So fällt man im schlimmsten Fall bei einem 60-Hz-Monitor dauerhaft auf 30 fps zurück, obwohl die GPU pro Frame vielleicht nur um die 20 ms Rechenzeit benötigt – also 50 Bilder die Sekunde ohne VSync schaffen würde.

Mit VSync gibt es nur noch vollständige Bilder, da aber der blaue Frame in einem Durchgang nicht ganz fertiggestellt werden kann, sieht man den vorherigen grünen zwei Mal hintereinander.​

VSync und die Swap Chain

Bevor ihr jetzt die Optionen öffnet und VSync wieder deaktiviert sei noch gesagt, dass dies bei den meisten Spielen nicht so ablaufen wird! Unter DirectX (was ja noch am häufigsten verwendet wird) kommt eine sogenannte »Swap Chain« zum Einsatz. Ist diese nur zwei Buffer lang, ist das äquivalent zur Doppelpufferung oben. In der Mehrheit der Titel besteht sie jedoch aus drei Gliedern, manche lassen es euch sogar einstellen.

Durch den zusätzlichen Platz eröffnet sich jetzt endlich die Möglichkeit anstatt des Wartens damit zu Beginnen in den letzten Buffer zu schreiben. Sollte die Grafikkarte also wie schon oben knapp länger benötigen als der Zyklus eines Bildaufbaus, so kann im zweiten Durchgang die überschüssige Zeit mit »vorbereiten« verbracht werden. Damit wird nun in der nächsten Runde genügend Vorarbeit geleistet sein, um das Bild fertigstellen zu können und nicht wieder auf die halben FPS zurückzufallen. Bei 25 ms erreicht man also beispielsweise selbst 40 fps auf 60 Hz, um jedoch weiterhin Screen Tearing zu verhindern, muss hierbei jedes dritte Bild doppelt angezeigt werden. Zwei Frames werden also für 1/60 Sekunde angezeigt und danach ein dritter für 2/60 = 1/30 Sekunde. Dieses leichte Stottern wird viele Leute nerven, die Latenz liegt nun aber zwischen 1/30 s und 1/40 s statt den definitiven 1/30 s bei doppelter Pufferung.

Zur besseren Übersicht ist nun der vordere Puffer immer ganz links und die Frames »rutschen« von rechts her durch. Keines der Bilder wird schneller gerendert als der Monitor für einen Refresh benötigt. Während jedoch das blaue ein weiteres Mal angezeigt werden muss, um den roten Frame zu finalisieren, kann die Grafikeinheit in der restlichen Zeit am grünen beginnen und braucht letztlich das rote Bild selbst nur einmal am Display ausgeben.​

Aber Achtung Mädels, es kommt nicht nur auf die Länge an! Sollte die GPU nämlich wieder mehr Bilder pro Sekunde schaffen, so werden beide Backbuffer »zu schnell« gefüllt und die Grafikkarte ruht erneut. Dabei bringt es zusätzlichen Lag der Länge eines Refreshs mit sich. Nichtsdestotrotz, mit der vollgeladenen, langen Schlange ist man bereit für den Härtefall, sollte unser gutes Stück also mal vor einer Angelegenheit stehen, die etwas mehr Saft verbraucht, so hilft die Reserve. Und bei minder anspruchsvollen, folgenden Aufgaben wird wieder weniger herausgeschossen als neu entsteht und jeder kann ohne Aussetzer befriedigt werden.

Der nasensekertfarbene Frame dauert fast zwei Bildwechsel zur Berechnung, da die Puffer davor gefüllt sind und die nachfolgenden Frames wieder schneller rendern, bekommt man am Monitor hiervon nichts mit.​

Adaptive VSync und Dynamic VSync Control

Was ist nun, wenn man die Mikroruckler von VSync überhaupt nicht ausstehen kann, auf alle Fälle bei mehr GPU-FPS als Display-Hertz aber trotzdem kein Tearing sehen will. Entweder man rennt heulend zu Mutti oder man schaltet VSync dynamisch an und aus (empfohlene Option der beiden Möglichkeiten). Bei nVidia kann man daher im Treiber für VSync die Option »Adaptiv« wählen und RadeonPro für AMD-Karten beherrscht die »Dynamic VSync Control«. Bis auf den Namen gibt es keinen Unterschied. Bei einer Bildschirmwiederholrate von zum Beispiel 60 Hz aktivieren beide VSync, solange die Grafikkarte auch 60 fps produzieren kann. Sollte dies nicht mehr möglich sein, wird VSync einfach solange deaktiviert, bis es wieder 60 fps werden.

Da der blaue Frame auch hier wieder mehr Zeit benötigt, wird grünen länger angezeigt, diesmal tauschen die Buffer jedoch während des Lesens und so entsteht mittig in der oberen Bildhälfte ein Tear.​

Maximum Frame Latency

Nicht nur zwischen Grafikkarte und Display wird ein Puffer benötigt, sondern auch von der CPU zur GPU. Meist auch »Maximum Pre-Rendered Frames« (nVidia), »Flip Queue Size« (AMD) oder »CPU/GPU Synchro« (TrackMania) genannt, beschreibt es die Anzahl der in DirectX von der CPU vorbereiteten Bilder, bevor diese zum Rendern an die GPU weitergegeben werden. Mit einem Wert von über eins kann hier nun der Prozessor (sofern er schnell genug arbeitet) die Frames zurückhalten und sich wie schon die GPU mit ihrer Swap-Chain einen wortwörtlichen Puffer verschaffen. Typischerweise liegt dieser Wert bei drei, für die reine Videowiedergabe lohnt sich aber auch ein höherer Wert, um noch stärkere Schwankungen kompensieren zu können. Bei interaktiven Spielen möchte man das Erhöhen der Latenz näturlich vermeiden, um aber einen Performanceverlust zu verhindern, ist die Funktion essentiell (besonders auf Multi-GPU-Systemen).

Gleichzeitig könnte solch eine sehr mächtige Einstellung missbraucht werden, indem diese in einem Benchmarkprogramm – bei jenem man eben nicht einfach die Kamera schwenken kann, um den Lag zu spüren – zu größerer Länge forciert wird. Bei einem einzelnen Grafikchip würde ein noch höherer Wert generell nur etwas bessere Minimums liefern, hätte aber nVidia bei Multi-GPU-Systemen über ihre tollen Treiber einen extrem hohen Wert erzwungen, um so die Leistungs-Skalierung zu verschönern, hätte Microsoft das doch schnellstmöglich unterbinden müssen. Aber wir wollen ja hier niemanden schlechtreden, das durch einen signierten Treiber mögliche Maximum ist seither wohl einfach nur zufällig auf vier Frames beschränkt worden – von mir dafür 3 ½ von 4 vollangebundenen Sterne.

Mafia II – powered by nVidia.​

In ihrer Gesamtheit ist solch eine Pipeline recht umfangreich und seit DX 12 mit »Asynchronous Compute« scheint an manchen Stellen etwas anders abzulaufen und OpenGL, beziehungsweise Vulkan werden wiederum unterschiedliche Implementierungen bieten. Letztlich werden die Entwickler in der Game-Engine einen festen Kompromiss vorgeben, zwischen der Aktualität der Maus- oder Tastaturinputs und einer Verhinderung von vereinzelten Rucklern, weshalb wir hier nicht zu tief ins Detail gehen werden.

Es sei aber noch gesagt, dass das Puffern zur »Interpolation« nötig ist. Sprich, in einem modernen Spiel muss entschieden werden, mit welcher Rate es sich lohnt den spielinternen Zustand zu aktualisieren und damit beispielsweise die Häufigkeit der Physik- und Animationsberechnungen zu limitieren. Will man aber nachher nicht als schlampiger Entwickler dastehen, sollte man keinesfalls die maximale Bildrate hierauf beschränken! Um den Spielern trotzdem hohe FPS zu ermöglichen, werden so beispielsweise Animationen interpoliert. Doch wie bei der Zwischenbildberechnung eures Fernsehgeräts benötigt man dafür mindestens zwei Werte. Der Prozessor muss also schon einen weiteren Animationsschritt berechnet haben, bevor Interpolationen für frühere Frames stattfinden. Damit werden selbst tausende Bilder pro Sekunde keine Verringerung des Input-Lags bewirken, sofern die Engine nur mit beispielsweise 60 Hz arbeitet. Monitore mit über 60 Hz bekommen hier also lediglich flüssigere Animationen.

Des Weiteren wird die fehlende Flexibilität nervig, sollte die Framerate unter die Rechenfrequenz der Game Engine fallen. Zum Schutz der Entwickler möchte ich hier keine Namen erwähnen, es ist aber unschön, die Kamerabewegung an letztere zu koppeln. Da meine HD 7870 an manchen Stellen in Frictional Games‘ SOMA nicht ganz 60 fps schafft, wollte ich mit flüssigeren 50 Hz @ 50 fps spielen. Doch Pustekuchen, die Kamera wird hier mit fixen 60 Hz geupdatet. Sprich, selbst mit exakt 20 ms langen Frames hat das Bild gestottert, da zehn Mal in der Sekunde eines dieser Kamerapositionen übersprungen wurde. Selbiges dürfte auch erneut bei den Animationen passieren, bis dahin war ich aber schon wieder bei 60 und auf hundertachtzig.

Sechzig Mal dürft ihr raten, woran die Physik in SpinTires gekoppelt ist.​

Enhanced Sync und FastSync

Diese Technologien sind die neusten Einfälle der hinterhältigen Grafikkartenhersteller, um euch zum Kauf eines neuen Produktes zu verlocken. So funktionieren sie jeweils auch nur mit den beiden neusten Generationen – FastSync auf Maxwell und Pascal, Enhanced Sync bei Polaris und Vega. *Sarkasmus aus.*

Update: Seit dem Adrenalin-Treiber klappt „Erweiterte Synchronisierung“ auch auf meiner Steinzeitkarte, damit gibt es also wohl dieses Feature auf allen Radeons.

Auch wenn deren Funktionsweise nicht exakt dieselbe ist wie OpenGLs Tripple-Buffering, so entsteht doch ein vergleichbarer Effekt. Nochmal zur Erinnerung, DirectX nutzt die Dreifachpufferung mit VSync für das geschmeidigste Erlebnis und Frames behalten immer ihre Reihenfolge bei (First-In-First-Out). Mit OpenGL können die beiden Backbuffer hingegen die Position tauschen. Wurden nun beide gefüllt, so wird das Bild des älteren verworfen und begonnen den nächsten zu zeichnen. Durch dieses Wegschmeißen arbeitet die GPU wieder ununterbrochen, da aber trotzdem immer in einem Backbuffer noch ein vollständiges Bild liegt, kann ein rissfreier Swap in den Frontbuffer stattfinden.

Die beiden Backbuffer rechts rechnen bei einer schnellen Grafikeinheit viele Frames »umsonst«. (Der Pfeil zeigt immer auf das aktuellste Bild.)​

Fast- und Enhanced Sync »modifizieren« nun einfach die First-In-First-Out-Queue, um dieses Ergebnis ebenfalls in DX-Titeln im Vollbild erzielen zu können. Einziger Unterschied bei AMDs Variante ist jedoch, dass unter der Bildschirmwiederholfrequenz VSync ausgeschaltet wird. Zusammen mit der »Frame Rate Target Control« (AMDs Frametime-Begrenzer) könnte man sich im Treiber also selbst eine Dynamic VSync Control zusammenbasteln. Bei den anderen beiden Techniken verhält es sich hier identisch zum »anderen« Tripple-Buffering.

Aber Moment, wenn es bei Werten unter der Refresh-Rate mit VSync zu Bildstottern kommt, passiert dann nicht auch dasselbe beim überschreiten? Die kurze Antwort: Ja. Ein aktuelles AAA-Spiel wird kaum so wie oben in dem GIF (bitte nicht »Jiff« aussprechen) mit der dreifachen Rate eures Monitors laufen. Sind die Frametimes hingegen kein ganzzahliger Teiler, so entsteht eine unregelmäßige Bildausgabe. Besonders extrem wird es je knapper sich die FPS über der Wiederholfrequenz befinden.

​

Die Zeit verläuft von links nach rechts und die dünnen, vertikalen Linien in der Abbildung beschreiben den Beginn eines Refresh-Zyklus, jeweils der letzte komplette Frame (als Rechteck dargestellt) wird ausgegeben. Das … Eins, Zwei, … das fünfte Bild wird nun leider etwas zu spät fertiggestellt und so muss auf das vorherige, deutlich ältere zurückgegriffen werden. Da zudem der nächste Frame innerhalb des aktuellen Intervalls gerendert werden kann, wird Nummer 5 nicht mehr benötigt und verworfen. Dessen Überspringen macht sich aber letztlich als kleiner Ruckler bemerkbar.

​

Bei VSync mit Doppelpufferung, welches ja obendrein die FPS limitiert, wird die Ausgabe hingegen sogar gleichmäßiger, da die GPU nach »zu schnell berechneten« Bildern pausiert und schließlich jedes äquivalent alt werden lässt.

Zum Abschluss des Abschnittes möchte ich noch erwähnt haben, dass Enhanced Sync und FastSync eigentlich nichts besonderes sind, da auf jeder Grafikkarte mit dem Wechsel zum (randlosen) Fenstermodus der identische Effekt durch den »Desktop Window Manager« erzwungen wird.


Reaktionszeit vs Display-Lag

In meinen Animationen habe ich bisher immer die Reaktionszeit der Bildschirmpixel ausgelassen. Soll jedoch ein Pixel eines LCD-Panels (aus drei Subpixeln bestehend – Rot, Grün, Blau) einen neuen Farbwert anzeigen, so müssen hierfür die Kristalle gedreht werden, um das Licht auf die gewünschte Helligkeit abzuschwächen. Dies dauert jedoch seine Zeit und durch die unterschiedliche Art des Rotierens geht es mit TN generell schneller als bei IPS. Könnte man also einen Monitor einfrieren, so sehe man an einer Stelle des Displays einen sanften Übergang zwischen zwei aufeinanderfolgenden Refreshs.

Diese Reaktionszeit ist also letztlich ein Indikator dafür, wie scharf der Bildschirm in der Bewegung aussieht. Bei manchen Monitortest wird so der Durchschnitt der Wechsel von tiefstem schwarz zu hellstem weiß und umgekehrt von weiß zu schwarz gemessen. Händler bewerben ihre Displays jedoch nicht mit dieser Schwarz/Weiß-Schaltzeit, sondern mit der »GTG« (grey-to-grey Zeit). Bei jener wird der Übergang zwischen zwei zehn Prozent entfernten Grautönen ermittelt, hier bleibt also ein gewisser Spielraum, um sich das Best-Case-Szenario herauspicken und schließlich auf die Verpackung drucken zu können.

Es sein noch erwähnt, dass Overdrive und Backlight-Strobing existieren, um die wahrgenommene Unschärfe zu verringern. Aufgrund des fehlenden Bezugs zum Rest des Artikels werde ich jedoch nicht weiter darauf eingehen. »Persistence« spielt eine wichtige Rolle, dazu finde ich aber hoffentlich in einem späteren Beitrag Zeit.

Viel wichtiger dürfte da schon der Input-Lag des Bildschirms sein. Hier ergibt sich durch die interne Logik, welche beispielsweise ermöglicht das Bild zu skalieren oder die Farben anzupassen, eine Verzögerung. Zudem kann auch ein komplettes Bild zurückgehalten werden, um dafür zum Beispiel einen dynamischen Kontrast zu berechnen (alternativ kann es auch einfach auf das folgende Bildsignal angewendet werden). Wie schon anfangs erwähnt, kann der Inhalt des Frontbuffers nicht sofort komplett angezeigt werden. Stattdessen findet der Wechsel von oben nach unten statt. Bei einer synchronisierten Ausgabe mit 50 Hz wird der Pixel ganz rechts unten somit eine zusätzliche Latenz von 20 ms haben.

​

Das obere Bild zeigt wie ein Neon-Schild in Deus Ex aussieht, wenn man still davor steht. Darunter (nachgestellte Szene) bewegt sich JC nach rechts, jetzt wirkt wegen der Reaktionszeit der Pixel alles etwas unscharf (nein, für die meiste Unschärfe ist die Persistence of Vision verantwortlich) und zudem entsteht eine Scherung durch die Dauer des Bildabtastung. Mit der doppelten Refresh-Rate würde sich letzterer Effekt halbieren, bei 60 Hz oder weniger ist es aber gut zu sehen – achtet beim nächsten Spiel einmal darauf oder schaut euch beide Auswirkungen auf TestUFO.com an. Für das statische Fadenkreuz ergeben sich diese Fehler hingegen nicht.


Adaptive-Sync

G-Sync (nVidia) und FreeSync (AMD) vereinen durch ihre variable Bildwiederholfrequenz endlich das beste aus beiden Welten. Einerseits werden Bilder unverzüglich an den Monitor weitergegeben, auf der anderen Seite werden sie ohne Tearing dargestellt. Kauft euch das augenblicklich und wir sind hiermit fertig… oder doch nicht?

Betrachten wir einmal wie die beiden arbeiten. Haben wir ein Gerät mit 100 Hz, so benötigt es 10 ms für die komplette Abtastung. Dies ist nun unser oberes Limit, jeder Frame schneller als die 10 ms wird außerhalb der G-/FreeSync-Range liegen. Beachten wir aber zuerst das, wofür sie gemacht wurden: zu niedrige FPS. Als Beispiel soll nun die GPU immer Frametimes einer Länge von über 10 ms liefern, so wird plötzlich ein Bild (Frame 2) erst nach 12,5 ms (1/80 s) fertiggestellt, oh nein! Aus Angst vor diesem Fall benötigte man bisher ein Glaubensbekenntnis gegenüber entweder VSync an oder VSync aus. Hier ist dies aber nicht mehr nötig, merkt jetzt die Radeon-Grafikkarte (bei AMD), beziehungsweise das überteuerte G-Sync-Modul (bei nVidia), dass das Rendern von Frame 2 nach einem Hundertstel noch nicht abgeschlossen ist, wird der nächste Refresh hinausgezögert (dargestellt durch den hellblauen Hintergrund in der Grafik – schaut halt schon runter). So ruht der Bildschirm (Reaktionszeit vernachlässigt) und das letzte Bild (Frame 1) bleibt weiterhin zu sehen.

​

In unserem Fall dauert es jetzt 2,5 ms bis der neue Bildaufbau beginnt. Ein Frame wird also so lange angezeigt, wie der nachfolgende im Backbuffer verweilt.

Bei einer Berechnungsdauer von nun 20 ms (1/50 s) würde der Monitor das vorherige Bild wieder 10 ms abtasten und danach 10 ms ruhen. Und bei 40 ms? 10 – 30? Hier spreche erst mal nichts dagegen, jedoch »entspannen« sich die Kristalle eines LCDs solange sie nicht refresht werden. Sie drehen sich daher automatisch wieder in ihre Ursprungsposition und lassen mehr Licht hindurch. Das Bild wird also langsam heller, bis auf einmal der nächste Bildwechsel startet und alles wieder leicht dunkler wird. Diese Helligkeitsschwankungen registriert man bei zu niedrigen Frequenzen letztlich als Flimmern. Es wird also auch ein unteres Limit benötigt.

Allerdings schwanken die Renderzeiten von einem Frame auf den nächsten (außerhalb von Early-Access-Spielen) eigentlich nie so einfach um die doppelte Länge, wie es in der Abbildung behauptet wird. Auf der einen Seite ist es daher nicht schlimm, dass der folgende Frame die Anzeigedauer des aktuellen bestimmt, andererseits können so schon Annahmen darüber gemacht werden, ob vielleicht bald die FPS aus der Sync-Range fallen würden. Überdecke diese also 50 bis 144 Hz – sprich 20 bis 6,9¯4 ms – sollten nicht die maximal möglichen 20 ms abgewartet werden, wenn der vorherige Frame schon 19 ms Renderzeit benötigte. Stattdessen könnte das Displays ohne pausieren ein weiteres Mal refreshen und dasselbe Bild erneut zeigen, um somit das Arbeitfenster auf 26,9¯4 bis 13,¯8 ms zu verschieben.

Dies sei aber nur ein Beispiel, weder AMD noch nVidia geben öffentlich an, wie entschieden wird, wann ein frühzeitiger Neuaufbau stattfindet und Bilder auf zwei oder gar mehr Refreshs aufgeteilt werden. Manche der ersten G-Sync-Modelle hatten beispielsweise zu lange Pausen zwischen den Refreshs, sodass sich viele Personen über das daraus resultierende Flickern beschwert haben – die Module neuerer Monitor besitzten dieses Problem nicht mehr. Seitens AMD wurde die Funktion unter dem Namen »Low Framerate Compensation« per Treiberupdate nachgepatch und realisierbar mit allen schon erschienenen FreeSync-Bildschirmen. Generell wird ein möglichst großer Frequenzbereich das dublizieren erleichtern, während jedoch bei G-Sync das Display vom Hersteller eine Übertaktungseinstellung bieten muss (welches aber letztlich auch nicht jedes Exemplar unbedingt problemlos schaffen wird), kann ein FreeSync-Monitor normal übertaktet und die Range-Limits in beide Richtungen erweitert werden.

Darüber hinaus funktioniert FreeSync neben Displayport auch über HDMI und generell bietet es meist mehr Anschlüsse als das G-Sync-Modul. Da sich auf einer (modernen) Radeon alles nötige befindet, muss auch keine latenzerzeugende Kommunikation zum Monitor hergestellt werden (bei nVidia verliert man aber auch nur Performance im Bereich von zwei oder drei Frames) und der 200 Euro Preisvorteil ist wohl der größte Pluspunkt – jetzt müsste es nur eine RX-Karte geben, die sich lohnt zu kaufen.

Ich könnte noch über G-Sync HDR und FreeSync 2 schreiben, wenn ich aber auf den Wortzähler schaue schreit mir dieser ein lautes »NEIN« entgegen. Erwähnenswert sei jetzt nur noch, dass diese Displays ab ihrer Höchstfrequenz identisch zu äquivalenten, gewöhnlichen Geräten laufen. Das heißt somit, dass hier weiterhin V-, Fast- oder Enhanced Sync ganz unabhängig arbeiten. Meine Abneigung gegen letztere habe ich schon kundgetan, aber was ist denn mit VSync und dem…


Lag, Laaag, Laaaaaaaaag

Bei einer Umfrage die ich vor über einem Jahr im GS-Forum gestartet hatte, war für über 56 Prozent der VSync-Ausschalter der Hauptgrund die niedrigere Latenz. So begrenzt auch die Hälfte nicht die FPS, aus entweder Angst vor wiederkehrendem Lag oder da ihre GPU immer langsamer als der Monitor ist oder ihnen selbst im Sommer so sehr kalt ist und die Stromrechung eh von den Eltern gezahlt wird

Die Gesamtverteilung der VSync-An- und Ausschalter seht ihr hier. Die Gegenfrage wurde hoffentlich schon zufriedenstellend beantwortet.​

Obwohl ich an manchen Stellen schon die Latenz einzelner Teilgebiete erwähnt hatte, stellt sich die Frage, wie es im Zusammenspiel in der Praxis aussieht. Nachfolgend habe ich daher den Input-Lag aus mindestens fünf Durchläufen jeweils verschiedener Einstellungen in Counter Strike: Global Offense und Alan Wake gemessen. Dieser Umfasst meine Reaktionszeit, die Mauslatenz, Verzögerung durch die CPU (samt GPU-Treiber, Grafik-API und Game-Engine) und Grafikkarte, sowie die Ausgabelatenz (und Pixel-Reaktionszeit) des Bildschirms. Da allerdings meine eigene Reaktionsgeschwindigkeit, die Mauslatenz, viele Schritte der CPU und der Display-Lag (im Durchschnitt) gleich bleiben, werden die uns interessierenden Stellen nicht beeinflusst.

Beginnen wir mit Counter Strike, hier gibt es in Steams Workshop eine Map zum Testen der Reaktionszeit. Eine weiße Wand wechselt die Farbe zu grün und währenddessen startet ein Zähler. Durch einen Schuss stoppt man diesen und die verstrichene Zeit wird angezeigt. Also genau das was wir suchen… wenn es denn funktioniert hätte. Nach ein paar komischen Resultaten habe ich mit OBS den Counter aufgenommen und festgestellt, dass dieser zu schnell zählt und als Ausgleich manchmal 70 ms hochspringt. Stattdessen werde ich also immer OBS verwenden und im Nachhinein die Anzahl der einzelnen Frames zählen.

​

Als erstes wird VSync deaktivieren und das interne FPS-Limit entfernt. Der Monitor läuft mit 60 Hz in Full HD, aufgenommen werden aber 250 fps (da CPU und GPU hier um die eintausend Bilder pro Sekunde schaffen) in herunterskalierten 480 x 270 Pixeln (um die CPU nicht zu belasten wird selbstverständlich in »ultrafast« encodiert). Als Ergebnis kommen wir auf einen Durchschnitt von 202,3¯8 ms (zum Vergleich, zwölf 60-Hz-Bilder entsprechen 0,2 s). Daraus können wir schließen, dass ich noch die Reaktionsschnelligkeit eines Dreizehnjährigen habe – naja, den kindischen Pipi-Kaka-Humor hab ich ja auch behalten. Als einziger Wert steht er aber recht zusammenhangslos dar. Also VSync mit Double-Buffering aktivieren (Aufnahmefrequenz in OBS wurde auf 120 fps gesenkt, 60 wäre hier aber auch genug), bäm, 266,¯6 ms. Mit Dreifachpufferung, bäm, 283,¯3 ms – oje. Wenigstens sind drei Buffer wie erwartet um 1/60 Sekunde langsamer, aber schon der Wert für zwei sieht leider überhaupt nicht gut aus. Sollte VSync also doch auf den Scheiterhaufen schlechter Grafikoption zusammen mit Tiefenunschärfe, Chromatischer Aberration, Motion-Blur und dem Vignetten-Effekt?

Nein! Der Wert der Maximum-Frame-Latency dürfte hier eine Rolle spielen. Durch die FPS-Begrenzung seitens VSync wird dieses Maximum dauerhaft erreicht, während vermutlich ansonsten ohne Limit die CPU die GPU schnellst möglich versorgen will. Und das werde ich euch jetzt beweisen. Dazu muss im Spiel lediglich die Konsole geöffnet werden und »fps_max« auf 59.9 gesetzt werden. Wird nun erneut gemessen, so sinkt die Latenz auf unglaubliche 200 ms. Doch wie ist das möglich? Durch obiges Kommando legt man fest, dass die CPU nur rund alle 16,694 ms einen neuen Frame liefert, die GPU aber natürlich am liebsten schon nach 16,¯6 ms ein Bild haben möchte. So wird der Prozessor keine Frames mehr zurückhalten und auch die Grafikkarte nicht ihren dritten Buffer füllen. Bei der Doppelpufferung kann sogar auf 60 fps limitiert werden und die Zeit bleibt weiterhin niedrig (203,¯3 ms). VSync mit Begrenzung und kein VSync ohne FPS-Cap sind somit (im Rahmen der Messungenauigkeit) identisch schnell!

Mit neuer Energie wurde dann das Capping auch ohne VSync getestet. Huch, 190 ms? Besser als ohne Begrenzer? Gleich nochmal probieren… hmn, selbes Resultat. Dann vielleicht fps_max 300… ah, 184,8 ms. Höhere Frameraten bringen also weiterhin einen (sehr marginalen) Vorteil, aber nur solange die eigene Hardware dauerhaft mithalten kann. Abseits dieser Map würden die 300 fps bei mir also schon nicht mehr erreicht werden und ein niedrigeres Limit wäre die schnellere Option.

Im nächsten Schritt soll nun VSync mit einem externen FPS-Capper arbeiten. Das im AMD-Treiber enthaltene »Frame Rate Target Control« bei 59 fps, sowie GeDoSaTo mit 59,9 fps haben jedoch keine Verbesserung gegenüber VSync alleine gebracht. Das liegt daran, dass beide ihr Limit erst bei der GPU anwenden, die CPU also ihren Zipfel trotzdem befüllen wird. Counter Strike wollte aber ebenso keine ein Frame große Flip Queue akzeptieren (weder über RadeonPro, noch direkt per Registry-Änderung). Erst RivaTuner brachte bei 59 fps die erhoffte Erlösung: 203,3 ms. Selbst ohne VSync verbesserte sich der Wert nicht und bei 60 fps mit doppelgepuffertem VSync lag der Lag wieder weit über 0,2 Sekunden. Der spielinterne Begrenzer bleibt also die erste Wahl.

Alle Werte in der Übersicht. FastSync und Enhanced Sync dürften sich knapp über 0,2 s einreihen.​

Übrigens, vsynctester.com meldet mir einen genaueren Wert meines Displays von rund 60,003 Hz, in den Radeon Settings und im Custom Resolution Utility sind es jedoch glatte 60,000 Hz, komisch.

Zu Beachten sollte man allerdings auch, dass bei einem 240-Hz-Display die Unterschiede in den Abständen viermal geringer werden. Selbst wenn dort also die CPU drei Frames der Länge 4,1¯6 ms (1/240 s) puffern würde, wäre es kürzer als ein einzelner 60-fps-Frame (12,5 ms vs 16,¯6 ms). Ein schnellerer Monitor ist also immer die beste Methode, um Latenzen zu verringern.

Bevor wir mit dem etwas alltäglicheren Titel beginnen (Konsolenport, grafisch Anspruchsvoll [zumindest für meine Senioren-Grafikeinheit]), wollte ich meine Schnelligkeit noch in einem Online-Reaktionstest unter Beweis stellen; 203,4 ms. In der normalen Desktopoberfläche von Windows erreichen wir also nicht die Höchstwerte von Counter Strike: GO im Fullscreen.

Bei Alan Wake geht es ähnlich zur Sache, diesmal wird auf das Einschlagen eines Blitzes im Cauldron Lake gewartet (erhellt das ganze Bild) und daraufhin gesprungen (ebenfalls über die linke Maustaste). Um diesmal aber ohne Begrenzer unter 60 fps zu kommen, wird eine »Virtual Super Resolution« von 2560 auf 1440 Pixeln verwendet (an der Benchmarkstelle herrschen rund 53 fps). Mit ausgeschaltetem VSync ergeben sich 223,2 ms und ist es aktiviert, sind es 243,6 ms. Da VSync hier nicht die FPS capt und damit keinen »Stau« durch Füllung aller Puffer bei CPU und GPU »verursacht«, sind die beiden deutlich näher beisammen. Der Durchschnitt von 243,6 ms zeigt jedoch nicht die ganze Wahrheit der vertikalen Synchronisation. Es hatten nämlich je fünf Messungen einen Durchschnitt von 226,4 ms und 260,8 ms, Werte im Bereich von 240 bis 250 Millisekunden wurden aber nie erreicht. Diese Differenz von 34,4 ms verrät uns jetzt, dass die Engine selbst wohl mit lediglich 30 Hz arbeitet (auf der Xbox 360 lief der Titel auch nur maximal mit 30 fps). Wäre meine Reaktionsgeschwindigkeit etwas langsamer, würde dies auch ohne VSync passieren und den Effekt der sinkenden Latenz bei höheren FPS sollte man hier nicht erwarten. Immerhin weist VSync bei 50 fps @ 50 Hz und 18 fps @ 72 Hz im Vergleich zu SOMA keine Mikroruckler auf.

​

Gehen wir ein letztes Mal zu 1080p. Ohne VSync ergeben sich 197,6 ms bei rund 84 fps, die Virtual-Super-Resolution dürfte vorhin also für etwas Latenz gesorgt haben. Ansonsten ist die Zeit aber äquivalent zur Performance in CS:GO. Mit VSync (und dadurch 60 fps) ergeben sich 250 ms. Obwohl hier also VSync zum »Stau« führt, entsteht etwas weniger Lag als in Counter Strike. Alan Wake dürfte der CPU also keine so lange Schlange erlauben. Überraschenderweise wird selbst nach dem Wechsel in den Fenstermodus die Verzögerung nicht größer (246,¯6 ms, praktisch identisch). Erst wenn man VSync im Spiel deaktiviert, fallen wir auf schlechte 266,¯6 ms zurück (und nein, ich habe hier nicht versehentlich die Werte vertauscht). Durch den Desktop-Window-Manager wird jedoch weiterhin Tearing verhindert, ähnlich OpenGLs Dreifachpufferung mit VSync. Da außerdem von den rund 84 pro Sekunde berechneten Bildern nur 60 angezeigt werden ergibt sich (wie schon prophezeit) die schlechteste Spielerfahrung.

Ungeachtet der ganzen Latenzunterschiede werden diese hingegen meist keine zu große Rolle spielen. Wie schon in einem älteren Eintrag erzählt, könnt ihr mit einem Zehen eure Stirn berühren und es fühlt sich an, als hätten sich beide gleichzeitig getroffen (probiert es gerne selbst aus). Die Nervenbahnen vom Gehirn zur Stirn sind jedoch um ein vielfaches kürzer als jene zu den Fußspitzen, so wird immer eine zusätzliche Verzögerung angewendet um alles korrekt zu Synchronisieren. Das heißt aber auch, dass sich euer Körper auch an den Lag eines Spiels gewöhnen kann. Dies kann etwas dauern, also gebt nicht direkt auf, bald wird es sich natürlich anfühlen.

Des Weiteren sind bei Online-Matches die eigene »Round Trip Time« (als Ping angegeben) und die Tickrate des Servers (vergleichbar mit der Arbeitsfrequenz der Game-Engine) die limitierenden Faktoren. Sie entscheiden, wie präzise Bewegungen und Schüsse letztlich sind, denn obwohl versucht wird diese Beschränkungen durch den Umweg über den Server zu kompensieren, ergibt sich eine gewisse Ungenauigkeit – diese wird aber im Kampf gegen Cheatereien in Kauf genommen. Wen das genauer interessiert, dem empfehle ich das Multiplayer-Networking in Source einmal näher zu betrachten.

​

Als zusätzlicher Punkt sind außerdem nicht nur Reaktionen auf visuelle Reiz vonnöten. Obwohl Audio natürlich ebenfalls gepuffert werden muss, sind für den Menschen die Reaktionsgeschwindigkeiten auf Sounds etwas flotter und der Tastsinn ist gar am schnellsten. In einer Racing-Sim wird man also eher hören oder dank Force-Feedback fühlen, wenn man gerade den Grip verliert. Würde man zuerst sehen, dass einen gerade das Heck überholt, ist es normal schon zu spät.

Man sollte darüber hinaus auch erwähnen, dass in wirklich wenigen Situationen solch »einfache Reaktion« gefragt ist, wie ich sie oben gemessen habe. Statt dem simplen Klicken muss oftmals eine Auswahl getroffen werden und zwischen mehreren Möglichkeiten entschieden werden. Damit meine ich nicht direkt TellTale Games, sondern die Option verschiedene Gegner anzuvisieren; vielleicht beim Unentdecktbleiben nicht direkt schießen sondern messern; mehrere mögliche Positionen abzusuchen, aus denen ein Feind auftauchen kann; die Entscheidung in eine bestimmte Richtung auszuweichen oder einen speziellen Angriff auszuführen. All jene resultieren in einer langsameren Reaktionsschnelligkeit und machen den Einfluss des restlichen Input-Lags geringer. Man kann sogar diese Entscheidungsfindung durch Training gut verringern und auch häufige Armbewegungen im Muskel verinnerlichen. Vermutlich wird es ebenfalls mehr bringen, wenn ihr die Muskeln eurer Finger oder der ganzen Hand vor dem Zocken aufwärmt (mit welcher Beschäftigung auch immer), anstatt noch die letzten FPS aus eurer Hardware zu quetschen.

In den wenigsten Spielen wird die Einfachreaktionsgeschwindigkeit entscheidend sein.​

Übersicht

Um einmal das Wichtigste aus dem doch etwas lang gewordenen Artikel zusammenzufassen und ein paar Empfehlungen auszusprechen:

Keine Synchronisation: Die Grafikkarte arbeitet uneingeschränkt, beziehungsweise so schnell es die CPU erlaubt. Buffer werden geswappt sobald ein neuer Frame gerendert wurde. Dem Display passt das leider überhaupt nicht und mitten im Bildaufbau entstehen Rissen. Mit je mehr Hertz der Monitor arbeitet, umso kürzer werden Tears zu sehen sein und weniger stören (sofern sie nicht [künstlich] an immer derselben Bildposition auftauchen).

Vertikale Synchronisation: Die GPU muss mit dem Schreiben in den Frontbuffer warten, bis der Bildschirm den aktuellen Refresh beendet hat, Tearing wird hier verhindert. Prozessor sowie Grafikeinheit puffern so viele Frames, wie es der Entwickler vorgesehen hat, um selbst in kurzzeitig anspruchsvollen Momenten das flüssigste und konsistenteste Spielgefühl zu ermöglichen. Beim häufigen Fallen unter die Bildschirmwiederholfrequenz sollte entweder VSync dynamisch ausgeschaltet werden (erneut entstehen Risse) oder auf eine mindestens drei Buffer lange Swap-Chain gesetzt werden (meist leicht unregelmäßige Ausgabe durch den Zwang auf das Refresh-Ende zu warten).

Adaptive Synchronisation: Vorgesehen für den gerade genannten Problemfall von zu niedrigen FPS, wird jetzt das erneute Abtasten herausgezögert, solange bis die Berechnung des nächsten Frames abgeschlossen ist. Zusammen mit VSync erreicht man also das beste Spielerlebnis. Spezielle Hardware ist jedoch erforderlich.

Nichtblockierende Synchronisation: Bei einer schneller als das Display arbeitenden GPU wird weiterhin auf das richtige Timing zum Tauschen gewartet. Zusätzlich mögliche Frames werden jedoch weiterhin berechnet und ersetzten dadurch gegebenenfalls ältere, nie ausgegebene Bilder. Trotzdem wird der niedrige Lag des synchronisationslosen Outputs nicht ganz erreicht. Die Frames pro Sekunde sollten zusätzlich deutlich über der Monitorrate liegen, um das Stottern zu vermindern. (Achtung, der [randlose Vollbild-]Fenstermodus erzwingt diese Synchronisation und dürfte für zusätzliche Latenz durch den Desktop-Window-Manager sorgen.)

Framerate-Capping: Achtung, es gibt verschiedene Arten! Zum einen können direkt im Spiel oder mit manchen externen Programmen die FPS in einer sehr frühen Phase limitiert werden. Dadurch kann die Verzögerung durch begrenzendes VSync aufgehoben werden. Dies heißt jedoch nicht, dass die exakten Frametimes auch beim Monitor ankommen. Ein Maximum von hier 100 fps kann bei der Grafikkarte zum Beispiel in Frametimes von 10 ms – 10 ms – 13 ms – 8 ms – 9 ms – 10 ms – 10 ms resultieren, wenn Nummer drei besonders hart für die GPU sein sollte. Alternativ kann aber auch bei der Grafikkarte begrenzt werden und 100 fps bedeuten dann auch minimal 10-Millisekunden-Frametimes. Es entsteht lediglich wieder eine ähnliche Füllung der Queues wie schon bei der Begrenzung durch aktiviertes VSync.


Wie sich letztlich herausgestellt hat, spielte unser Möchtegern-CS:GO-Profi die ganze Zeit im Borderless-Fullscreen, also unter erzwungenem VSync. ¯o¯