120Hz TFT und vsync Games?

W

wyb

Gast
Hi, ich überlege momentan mir einen 120Hz TFT zuholen (den Samsung RZ233), allerdings stellt sich mir eine Frage:

Bei Spielen wo ich vsync aktiviere geht es ja nicht nur um das tearing sondern auch um konstante >60<fps, damit es nicht ruckelt.


Wenn ich mir jetzt einen 120hz TFT hole und in manchen Spielen vsync aktiviere, muss meine Grafikkarte ja dauerhaft 120fps schaffen für ein gutes Spielgefühl.

Und dies ist in Titel wie GTA4 ja nicht machbar. Zb in GTA4 75fps an manchen stellen die dann sehr schnell zu 40fps wechsel -> unschöne ruckler.


Würde mich über ein paar Ehrfahrungen von 120Hz TFT usern freuen.


Danke
 
mit vsync verhinderst du nicht das es ruckelt sondern das das Bild zereist wenn dein PC keine 60 FPS schaft wird vsync daran nichts ändern und es wird ruckeln.

Die Lösung deines Problemes ist einfach stelle bei solchen spielen einfach keine 120 Herz ein sonder 60 am Monitor.
 
Letztendlich sorgt VSync doch nur dafür, dass ein Bild nur alle x/Hz-Zahl Sekunden gezeigt werden kann. Sprich hat man 60 Hz, das zweite Bild ist aber schon nach 20 ms fertig, muss man trotzdem bis zur 33. ms warten, bis das Bild auf dem Monitor gezeigt wird. Das heißt im allerschlimmsten Fall hat man einen "unnötigen" Lag in Form von 1/Hz-Zahl Sekunden, was selbst bei nur 60 Hz schon nur 17 ms sind.
Von daher ändert es im niedrigen fps-Bereich nicht viel, ob man Sync nun bei einem Monitor mit 60 oder 120 Hz aktiv hat, nur der mit 120 Hz zeigt eben bis 120 fps auch noch vernünftig an.
 
Ja aber man benutzt vsync ja auch dafür, dass man konstant 60fps hat, ohne dropps etc.

Einfach für ein gutes Gameplay, wenn ich von 80fps auf 50 falle, macht sich das sehr wohl bemerkbar.
 
Nein. Vsync verursacht die Drops. Wenn du keine 120FPS erreichst(auch wenn nur 0,1Frames fehlen), halbiert sie Vsync dank Double Buffering auf 60FPS. Bei unter 60 FPS werdens dann natürlich noch weniger.
Was Drops verhindert ist Tripple Buffering.
 
Bist du dir da sicher, Airbag? Auch aus dem Wikipedia-Artikel zu VSync geht mein Stand der Dinge hervor, nämlich dass mit einem fertigen Frame solange gewartet wird, bis der Monitor ein neues Bild darstellen kann (-> x/Hz-Zahl Sekunden vergangen sind, wobei x eine Ganzzahl sein muss). Sprich sinkt die Framerate unter die Rate für VSync wird nicht die Rate für VSync geändert sondern der Frame muss einfach solange warten, bis wieder ein komplettes Bild ausgegeben wird.

Gehen wir hier von einem imaginären Szenario mit einem 100 Hz Monitor und 80 fps aus, sähe das also wie folgt aus:
0 ms Frame 1 Darstellung
10 ms Frame 1 Darstellung
12,5 ms Frame 2 fertig
20 ms Frame 2 Darstellung
25 ms Frame 3 fertig
30 ms Frame 3 Darstellung
37,5 ms Frame 4 fertig
40 ms Frame 4 Darstellung
50 ms Frame 5 fertig und Darstellung
60 ms Frame 5 Darstellung
62,5 ms Frame 6 fertig
usw.
Angezeigte Bilder: 1; 1; 2; 3; 4; 5; 5
Dabei entstehen höchstens "Mikroruckler", da teilweise Frames doppelt gezeigt werden müssen.

Zu Drops: Die kommen natürlich auch mit VSync vor, nur weil VSync aktiv ist rechnet die Karte doch nicht plötzlich schneller. Allerdings macht die Karte nach der VSync-Frequenz einfach dicht und hört auf zu rechnen, da sowieso nichts mehr dargestellt werden könnte. Das heißt höher ist nicht möglich, niedriger schon.

edit: Kleine Nebeninfo (die ich aber schon erwähnt habe):
Die maximale Verzögerung für einen fertigen Frame beträgt 1/Hz-Zahl, da danach auf jeden Fall wieder ein Frame angezeigt werden kann. Entsprechend entsteht bei zu niedrigen Framerates auch kein richtiges Mikroruckeln, denn die maximale Abweichung von der tatsächlichen Ausgabezeit beträgt entsprechend jene Zeit, beispielsweise könnte der eine Frame 5 Aktualisierungen brauchen und der nächste 6, der Unterschied in der Darstellungszeit würde also (im oben genannten Beispiel) nur 10 ms betragen, was bei 50 und 60 ms nun kaum auffällt.
 
Zuletzt bearbeitet:
Bist du dir da sicher, Airbag? Auch aus dem Wikipedia-Artikel zu VSync geht mein Stand der Dinge hervor, nämlich dass mit einem fertigen Frame solange gewartet wird, bis der Monitor ein neues Bild darstellen kann (-> x/Hz-Zahl Sekunden vergangen sind, wobei x eine Ganzzahl sein muss).
Ich habe nicht das Gegenteil behauptet, sondern genau, dass was du aus dem Wikiartikel hast.

Trippel Buffering hilft nur dagegen. Nämlich mit einem zweiten Backbuffer.
 
VSync gibt dir aber keine Konstanten 60fps. Es limitiert nur nach oben, aber wenn mal die 60 fps nicht erreicht werden gibts trozdem einen Drop und der fällt dann sogar schlimmer aus, da mit den 60Hz synchronisiert. Damit dropt man kurz auf 30 fps. Ob man das jetzt "Mikroruckler" nennt ist egal, es ist dem Verhalten bei CF oder SLI ähnlich, aber trotzdem auch ein FPS-Drop.

Der Tripple-Buffer schwächt das ganze etwas ab und sollte bei V-Sync auf jeden Fall mit ein sein (ansonsten kann die Karte beim Warten auf den nächsten Sync-Zeitpunkt nichts berechnen). Aber trotzdem wird das ganze durch V-Sync nicht flüssiger. Es wird nur das Tearing verhindert, was aber für mich alleine schon Grund genug ist V-Sync zu verwenden.
 
Hää? Ist das auf die Aussage von TE bezogen oder meine ?
Wenn meine, dann habe ich es nirgendwo behauptet.

edit:
Okay war auf #4 bezogen.
 
Dieser "Triplebuffer" (Bei mir in den Treibereinstellungen "Dreifachpuffer" genannt) bewirkt Folgendes?
Erster Puffer = Ausgabe
Zweiter Puffer = Frame, der wartet
Dritter Puffer = Frame nach dem Frame, der noch nicht dargestellt wurde?

Falls ja dürfte das doch nur bei niedrigen fps (= unterhalb der Hz-Zahl) etwas bewirken, da dann theoretisch 100%-GPU-Zeit notwendig wäre, aber aufgrund der Synchronisierung keine 100% bereitgestellt werden, oder?
 
Ja, der Tripple-Buffer ist nur notwendig, wenn die FPS unter der Bildwiederholrate liegen, aber dann verbessert er die Performance.

Aber wenn man konstant 60 FPS garantieren kann sollte man sich überlegen ob man nicht mehr Details zuschalten sollte oder ein aktuelleres Game zocken sollte ;-)

PS: ja ich weiß, das CS und ein paar andere Games anders reagieren, aber ich zieh daraus keine Vorteil ;-)
 
Erster Puffer = Ausgabe
Zweiter Puffer = Frame, der wartet
Dritter Puffer = Frame nach dem Frame, der noch nicht dargestellt wurde?

Ja, wenn der eine Backbuffer mit dem Frame fertig ist, wird geswapt(Adressierung von Front und Backbuffer getauscht ) und der andere Backbuffer rendert dann auch schon das nächste Bild. Somit sind beispielsweise 90FPS bei 100Hz wirklich 90FPS und nicht 50.
 
Genau genommen wären 90 fps bei 100 Hz ja nur kurzzeitig 50 fps, alle 9 Frames, wenn ich nicht daneben liege :D

Aber wenn es doch nichts gibt, das gegen den 3. Puffer spricht, wieso sollte man die Funktion überhaupt deaktivieren können?
 
AP Nova schrieb:
Genau genommen wären 90 fps bei 100 Hz ja nur kurzzeitig 50 fps, alle 9 Frames, wenn ich nicht daneben liege :D

Das gilt eben nur bei aktiven Tripplebuffer. Ansonsten muss die Grafikkarte ständig warten und das ganze bricht auf dauerhaft 50fps ein.

Was gegen den Tripplebuffer spricht? Er braucht etwas Speicher (ist aber auch nicht viel, Breite*Höhe*4 Bytes, bei FullHD sind das knapp 8MB) und es führt insgesamt zu einer kleinen Verzögerung zwischen Berechnung und Anzeige (Inputlag). Ist aber eigentlich zu vernachlässigen.

V-Sync und Tripplebuffer sind eigentlich mit das Erste, was ich den Grafikoptionen eines Spiels einschalte (die Option im Treiber ist ja nur für OpenGL, bei DirectX regelt das jede Anwendung selbst).
 
Stimmt, ohne Triplebuffer wird die Zeit am Ende ja immer verschenkt...

Bist du dir sicher, dass die Treibereinstellungen nur für OpenGL gelten? IL2 und Star Wolves (ist jetzt nicht so bekannt, nur um zu zeigen, dass es da auch geht) akzeptieren ihr AA und sonstwas über das nVidia Panel, das einzige was mir auffiel war, dass IL2 nur im OpenGL Modus auch durchsichtige Texturen glättet (Die "Seile", die teilweise an Flossenspitzen reichen sind primär gemeint).
 
Aber wenn es doch nichts gibt, das gegen den 3. Puffer spricht, wieso sollte man die Funktion überhaupt deaktivieren können?
Wahrscheinlich auch noch die DX Spezifikationen. Per Treiber ist Triple Buffering nur bei OpenGL zu erzwingen. Ansonsten ist die Nutzung von externen Tools notwendig.
Außerdem die Speicherproblematik die es früher mal gab. 50-60MB sind heutzutage aber zu vernachlässigen.
 
50 bis 60 MB für einen Ausgabepuffer? Selbst 1920 * 1200 hat kaum über 2 MP, macht bei 4 Byte pro Pixel nicht einmal 10 MB.
 
8MB die von Jesterfox sind aber ohne AA.
Natürlich gibt es mit Triple Buffering auch Nachteile. Einerseits wird die Bildausgabe um ein weiteres Frame verzögert. Andererseits steht weniger Speicher für Texturen zur Verfügung, da ein kompletter Backbuffer nicht gerade klein ist. Bei 1024x768 verbraucht man mit Triple Buffering immerhin 3 MB zusätzlichen Framebuffer-Speicherplatz, bei 4x Anti-Aliasing "on Scanout" (auf GeForceFX ab NV35) sind es sogar 12 MB.

Dieser Unterschied erklärt sich im übrigen folgermaßen: "Normalerweise" wird sofort downgefiltert. Dazu werden bei 4x Anti-Aliasing die vier Farbwerte gelesen und die Mischfarbe als Pixel wird wieder geschrieben. Beim "Downfilter on Scanout" liest die RAMDAC-Logik die vier Farbwerte und mischt sozusagen on-the-fly das finale Pixel zusammen. Man spart sich dabei den Schreibzugriff des fertig gefilterten Pixels in den Framebuffer.
 
Zuletzt bearbeitet:
Zurück
Oben