Vsync mit Triple Buffer vs. GSync

[SamLombardo]

Hallo. Wie ist eigentlich die Wirkung von Vsync mit aktiviertem Triple Buffer (etwa über den D3D Overrider) im Vergleich zu gsync. Ich hab jetzt schon mehrmals gelesen, dass das Ergebnis ähnlich ist, abgesehen vom leicht erhöhten Input Lag. Ist da was dran, oder ist das Quatsch? Hat jemand dazu Erfahrungen?

Danke.

[aufkrawall]

Das Ergebnis ist natürlich viel schlechter, weil einige Frames länger angezeigt werden müssen als andere, wodurch es stottert.
Außerdem ist der Input Lag viel höher (weil TB eben nur noch eine simple Frame-Queue ist).

[captain_drink]

Das Ergebnis ist natürlich viel schlechter, weil einige Frames länger angezeigt werden müssen als andere, wodurch es stottert.
Außerdem ist der Input Lag viel höher (weil TB eben nur noch eine simple Frame-Queue ist).

Bei "echtem" TB (im Gegensatz zu flip size queue/render ahead), etwa via D3DOverrider, wird nichts länger als durch die Refresh Rate bedingt angezeigt, dazu gibt es ja den dritten Buffer. Der Input Lag ist daher auch identisch mit no vsync.

[aufkrawall]

Es gibt kein "echtes" TB mehr, nirgends. Wo soll es das zuletzt gegeben haben?
Edit: Der Lucid-Schrott stottert ja auch extrem.

Edit 2: Bliebe noch Aero. Bei AC: U konnte ich allerdings keinen Unterschied beim Lag zu normalem Vsync im FSE bemerken.

[robbitop]

G/A-Sync ist nicht grundlos so abgefeiert worden. Ich würde mir heute (zum Spielen) keinen Monitor mehr ohne kaufen.

[captain_drink]

Es gibt kein "echtes" TB mehr, nirgends. Wo soll es das zuletzt gegeben haben?
Edit: Der Lucid-Schrott stottert ja auch extrem.

Edit 2: Bliebe noch Aero. Bei AC: U konnte ich allerdings keinen Unterschied beim Lag zu normalem Vsync im FSE bemerken.

D3DOverrider war bisher mit fast allem, was ich gespielt habe, kompatibel. Eine Ausnahme war Serious Sam: BFE, das hatte aber internes TB.

Aero ist keine Alternative, das ist auch kein echtes TB.

[aufkrawall]

Ich sagte es glaub ich schon mal vor einiger Zeit: Ich konnte mit Vsync per D3DOverrider afair kein Rubberbanding vermeiden, der Lag von adaptivem Vsync per Treiber war am geringsten.

[captain_drink]

Vielleicht eine falsche Version o.ä.? Bei älteren fehlt die DX10-Kompatibilität.
Ich habe mit v2.0.1 hier jedenfalls nirgends Tearing oder Input Lag. Lässt sich direkt reproduzieren, TB on/Vsync off fühlt sich exakt gleich an.

[aufkrawall]

Beim letzten Versuch funktionierte das Tool jedenfalls nicht.
Kannst du mir deine Version wo hochladen?

[captain_drink]

Bitteschön: http://www.file-upload.net/download-10306825/D3DOverrider.zip.html

[aufkrawall]

Danke. Mal sehen, was mit der 9600 GT so geht. :redface:

[derF]

Was versteht ihr unter "echtem" Triple Buffering? Und warum tritt da nicht das von aufkrawall genannte Problem auf:

Ausgangslage: 60 Hz-Bildschirm, 40 fps
Ergebnis: Anzeige der Frames abwechselnd ein Refresh und zwei Refreshes.
Zehn Refreshes: 1 - 2 - 2 - 3 - 4 - 4 - 5 - 6 - 6 - 7

[captain_drink]

Was versteht ihr unter "echtem" Triple Buffering?

http://www.anandtech.com/show/2794/2

[Tesseract]

Was versteht ihr unter "echtem" Triple Buffering?
bei render ahead hast du eine queue von X frames, der inputlag ist dabei immer so lange wie die queue und wenn die fps runter gehen und damit die queue zeitlich länger wird bekommt man ein extremes gummiband. klassischer triple buffer hat 3 buffer, wobei die GPU immer abwechselnd in die beiden backbuffer rendert aus denen gerade nicht ausgegeben wird und wenn der bufferswap erfolgt wird der backbuffer genommen der das aktuellste fertige frame enthält. dadurch ist der inputlag im schnitt sehr gering und die double buffer problemtik mit der doppelten frameausagbe ist auch sehr reduziert.

render ahead ist eigentlich totaler unsinn für spiele, damit hat man zwar die beste performance und homogenität aber geht dabei über die maximale zahl an inputlag-leichen.

Es gibt kein "echtes" TB mehr, nirgends. Wo soll es das zuletzt gegeben haben?
verwendet OpenGL nicht echten triple buffer?

[captain_drink]

verwendet OpenGL nicht echten triple buffer?

Lässt sich jedenfalls bei AMD und NV treiberseitig forcieren. Bei DX ist es seit einer bestimmten Version (vergessen welche) hingegen nicht mehr vorgesehen.

[derF]

Ok, der Effekt der unrunden Frame-Anzeigedauer bleibt halt bestehen, solange fps < Hz. Aber der Inputlag wird natürlich relativ gut minimiert.
Anderer Nachteil ist, dass die Grafikkarte intern Vollgas rendern muss, während mit A/G-Sync ein Framelimiter eingesetzt werden kann.

[Tesseract]

Anderer Nachteil ist, dass die Grafikkarte intern Vollgas rendern muss
sie muss nicht, sie kann. man könnte das ganze auch beliebig limitieren (z.B. auf 2 oder 3 frames) wobei ein limit von einem frame dann dem double buffer entsprechen würde.

[captain_drink]

Ok, der Effekt der unrunden Frame-Anzeigedauer bleibt halt bestehen, solange fps < Hz. Aber der Inputlag wird natürlich relativ gut minimiert.
Anderer Nachteil ist, dass die Grafikkarte intern Vollgas rendern muss, während mit A/G-Sync ein Framelimiter eingesetzt werden kann.

Ersteres macht sich nur bemerkbar, wenn die FPS deutlich unter der Refresh Rate liegen. Vgl.:

The software is still drawing the entire time behind the scenes on the two back buffers when triple buffering. This means that when the front buffer swap happens, unlike with double buffering and vsync, we don't have artificial delay. And unlike with double buffering without vsync, once we start sending a fully rendered frame to the monitor, we don't switch to another frame in the middle.

This last point does bring to bear the one issue with triple buffering. A frame that completes just a tiny bit after the refresh, when double buffering without vsync, will tear near the top and the rest of the frame would carry a bit less lag for most of that refresh than triple buffering which would have to finish drawing the frame it had already started. Even in this case, though, at least part of the frame will be the exact same between the double buffered and triple buffered output and the delay won't be significant, nor will it have any carryover impact on future frames like enabling vsync on double buffering does. And even if you count this as an advantage of double buffering without vsync, the advantage only appears below a potential tear.

Einen ähnlichen Effekt hat man auch, wenn die (potenziellen) FPS deutlich über der Refresh Rate liegen. Daher habe ich bei Bioshock 2 z.B. via D3DOverrider TB forciert und einen Framelimiter=60 gesetzt, damit waren die Frametimes perfekt.

[aufkrawall]

verwendet OpenGL nicht echten triple buffer?
In Serious Sam 1 hatte ich mit Vsync Rubberbanding aus der Hölle.
Ebenso in CS 1.6, wenn ich Vsync TB über den Treiber forciere.

Das Prerenderlimit im Treiber festlegen hat übrigens keinen Einfluss auf die Vsync-Queue. Zumindest schlussfolgere ich das, da ich durch das Begrenzen auf einen Frame noch keine DB-Symptomatik provozieren konnte. Entsprechend sollten das unterschiedliche Queues sein.

Leider laufe ich momentan mit dem Athlon 64 X2 3800+ bei jedem alten Scheiß ins CPU-Limit und CS 1.6 ist nur noch OpenGL only, kann ich D3DOverrider somit momentan nicht wirklich testen.

[Tesseract]

Das Prerenderlimit im Treiber festlegen hat übrigens keinen Einfluss auf die Vsync-Queue. Zumindest schlussfolgere ich das, da ich durch das Begrenzen auf einen Frame noch keine DB-Symptomatik provozieren konnte. Entsprechend sollten das unterschiedliche Queues sein.

meinst du jetzt d3d? die flip queue size bei AMD macht das jedenfalls garantiert, da ist nicht nur der inputlag deutlich besser sondern auch die DB-problematik sofort da. bei nvidia macht es zumindest diese eine SLI-option definitiv auch und das normale prerenderlimit soweit ich weiß auch - zumindest hat sie das mal.

[aufkrawall]

Ja, bei D3D. OpenGL hab ich nicht entsprechend mit Vsync getestet, da bei diesen meist alten Gammelspielen der Input Lag eh komplett durch die Decke geht oder die fps immer hoch genug sind.
Bei NV löst prerenderlimit 1 mit Vsync bei D3D kein DB-Verhalten aus, gerade mit HL2 getestet.

Kann übrigens sein, dass bei AMD die Option nicht mit allen APIs funktioniert? Bei Skyrim war mir definitiv ein Unterschied aufgefallen, bei Max Payne 1 aber nicht.

[SamLombardo]

Bitteschön: http://www.file-upload.net/download-10306825/D3DOverrider.zip.html
Für 64 Bit Anwendungen funktioniert das aber nicht....oder?

[captain_drink]

Für 64 Bit Anwendungen funktioniert das aber nicht....oder?

Leider nicht, nein.

[SamLombardo]

Danke. Schade;)

[Tobalt]

einfaches vsync:

vsync mit double oder triple buffer ist not gegen elend! absolut nutzlose Modi außer double buffering in anspruchslosen games wo man 100% die refreshrate erreicht.


adaptives vsync:

dieses adaptive single/double buffering, was nvidia vor 2 jahren einführte, ist eine Super sache, da es auf jedem monitor funktioniert, und die schwächen von single und double buffering behebt.

adaptive sync

gsync/freesync hat keinen zusätzlichen lag gegenüber single buffering und eliminiert tearing. Also die ideale lösung, aber auf sehr neue monitore begrenzt.

[SamLombardo]

Ich hab im Netz gelesen, dass man Triple Buffering in D3D über die pre rendered frames erreichen könnte. So wäre mit pre rendered frames auf 2 und force vsync on im Treiber Triple Buffer aktiv. Ist das so, oder Blödsinn?

[captain_drink]

Ich hab im Netz gelesen, dass man Triple Buffering in D3D über die pre rendered frames erreichen könnte. So wäre mit pre rendered frames auf 2 und force vsync on im Treiber Triple Buffer aktiv. Ist das so, oder Blödsinn?

Letzteres. Das ist nur eine einfache flip size queue und hat mit echtem Triple Buffering und dessen zusätzlichem Buffer wenig bis nichts zu tun. Siehe auch den von mir oben geposteten Artikel von Anandtech.

[SamLombardo]

Danke für die Aufklärung.