Diskussion zu: nVidias "Adaptive VSync Technology" - die wahrscheinlich ...

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/nvidias-adaptive-vsync-technology-die-wahrscheinlich-interessanteste-kepler-neuerung


Für den Fall irgendwelcher Sprüche in Richtung "NV-Progaganda-News": Der "eiserne AMD-User" bin ich (zumindest in den letzten Jahren).

[aufkrawall]

TB wird mit keinem Wort erwähnt - warum nicht?
So vermittelt der Artikel ein falsches Bild von Vsync in der Praxis.

[y33H@]

TB hält dir zwar die Framerate oben, dafür hast du einen höheren Inputlag - vom Regen in die Traufe.

[aufkrawall]

TB hält dir zwar die Framerate oben, dafür hast du einen höheren Inputlag - vom Regen in die Traufe.
Nicht generell, nur bei doofen Anwendungen.
Etwa Battlefield 3 ist mit TB immer noch schnell genug, die Source-Engine wird arschlahm.

Adaptives Vsync ist in meinen Augen total schwachsinnig: Gerade bei niedrigen FPS-Raten sollte Vsync an sein, da hier das Tearing um so mehr auffällt.
Außerdem sind Shooter doch mit wechselndem Input-Lag (Vsync an/aus/...) auch nicht mehr wirklich spielbar.

[samm]

Also mir ist die LOD-Anpassung bei SGSSAA mehr wert als dieses Feature ;) Wobei ich durchaus denke, dass nvidia da gleichziehen wird.

Die Frage ist wirklich, da ja die Framerate analysiert werden muss, damit es wirklich dynamisches VSync und nicht nur ein Framerate-Limiter ist, ob es nicht seinerseits Lag resp., wie aufkrawall anmerkt, Schwankungen im Lag (xD) verursacht.

[aufkrawall]

Also mir ist die LOD-Anpassung bei SGSSAA mehr wert als dieses Feature ;) Wobei ich durchaus denke, dass nvidia da gleichziehen wird.

Ich hab es zwar schon an anderer Stelle gepostet, aber die Diskussion wiederholt sich ja: Ich persönlich hätte über den Treiber forcierbares TB Vsync für alle APIs sinnvoller gefunden.
Entweder, ich nutze Vsync gar nicht, oder eben TB.


Die Frage ist wirklich, da ja die Framerate analysiert werden muss, damit es wirklich dynamisches VSync und nicht nur ein Framerate-Limiter ist, ob es nicht seinerseits Lag resp., wie aufkrawall anmerkt, Schwankungen im Lag (xD) verursacht.
Muss ja eigentlich, sonst würde es bei 60fps auch noch Tearing geben.

Auf jeden Fall ist das neue Feature ein guter Marketing-Coup, sogar das 3DCenter macht Werbung dafür. ;)

[san.salvador]

Bei nvidia wird TB bei 99% aller Spiele forciert und es gibt dort keine springenden Frames.

Ich weiß noch nicht ob ich das jetzt als simple Werbung oder hundsmiserablen "Beitrag" werten soll. Aber jemand, der sich mit der Thematik auskennt, schreibt so einen Salat nicht zusammen.

[foenfrisur]

bringt denn adaptive vsync auch noch "merklich" etwas bei einem 120hz monitor?

vermutlich ja, aber minimal oder?

denn mir ist tearing mit 120hz "deutlich" weniger aufgefallen, als bei 60hz.

ich muss echt mal testen, ob 90-120fps+@120hz (ohne vsync) besser fürs auge wirkt, als 60fps@vsync.


mfg

[Mad-Marty]

Ich bezweifle ebenfalls das das ganze soviel besser als Triple Buffering ist ...

Ich spiele ziemlich viele Spiele mit TB, und bin ebenfalls der Meldung das hätte in diesen Beitrag reingehört, anstatt die Nvidia lösung als die jahrzente lang gesuchte Lösung von double buffering fps sprüngen darzustellen.

Und die meisten Spiele funktionieren sehr zufriedenstellend mit TB, gerade wenn man mal nur 45 fps schafft irgendwo.

Das ganze wirkt fast schon wie Herstellermarketing.

Fazit: Die Idee ist vielleicht ganz gut, der vermittelte Eindruck es würde ohne dieses Feature nicht gehen ist unsinn.

[Leonidas]

Das ganze wirkt fast schon wie Herstellermarketing..



Ist es aber nicht. Es hindert natürlich niemand NV daran, bei uns mal was einzuzahlen, aber das wird wohl nicht passieren.

Wenn, dann habe ich TB vergessen zu erwähnen. Wobei mir bei TB derzeit unklar, wo dieses aktiv ist - forcieren kann man es ja scheinbar nicht unter DX.

[san.salvador]

Ist es aber nicht. Es hindert natürlich niemand NV daran, bei uns mal was einzuzahlen, aber das wird wohl nicht passieren.

Wenn, dann habe ich TB vergessen zu erwähnen. Wobei mir bei TB derzeit unklar, wo dieses aktiv ist - forcieren kann man es ja scheinbar nicht unter DX.
Bei nv ist TB in Dx immer forciert und nicht abschaltbar, wenn Vsync an ist. Bis auf ~4-5 Spiele klappt das.

Sry, aber wenn einem das neu ist, dann sollte man solche Texte vielleicht gar nicht erst verfassen, geschweige denn veröffentlichen.

[boxleitnerb]

^ genau das. Vielleicht könnte mal jemand Beispiele nennen, wo dies nicht funktioniert. Es werden nicht viele sein.
VSync an heißt in dem Fall aber wohl erzwungen. Ich habe schon gelesen, dass wenn die Anwendung VSync kontrolliert, dann kein TB aktiv ist. Per Treiber erzwingen und schob hat man TB.

[Döner-Ente]

Meiner Erfahrung nach ist das API-abhängig. Vsync ohne TB ist mir in letzter Zeit nur in DX10/11-Spielen vorgekommen (Crysis 2, Far Cry 2 DX10, Fear 3, Two Worlds II DX 10), dann muss mans halt per D3D-Overrider forcieren.

OT: Einen Sinn sehe ich in adaptiven Vsync nur in dem Szenario, dass man zu 99% Fps >Hz-Limit (und damit Vsync an) hat und damit leben kann, dass in den restlichen 1% das Bild zerrissen wird.

Für Leute wie mich, die zu 99% eher Fps<Hz-Limit haben und die Vsync genau deswegen anschalten, um kein Tearing zu haben, ist es schlicht sinnlos.

[Blackhand]

Also ich benutze nach wie vor meinen CRT meist auf 1152x864@117Hz und Tearing fällt mir nie oder nur kaum auf und wenn es doch mal merklich auftaucht dann ist es auch wieder nicht soo störend. Von daher ist Vsync bei mir auch immer aus.

Bei meinem neuen Mitbewohner hab ich Tearing allerdings dann doch mal auf nem 60Hz TN-Panel miterleben dürfen und mitgekriegt wie scheiße das dort kommt, sowas hab ich ja noch nie erlebt. Deswegen wird in neuerer Zeit wohl so ein großes Trara um Vsync gemacht.

Eventuell ist der Effekt aber auch bei Widescreen-Displays generell störender. Dazu müsste sich mal ein FW900-User hier äußern.

Wie oben erwähnt wird Tearing auf einem 120Hz LCD wohl auch schon viel weniger störend sein, wenn es auftritt und abgesehen davon, dass es dann schon generell weniger zu Tearing kommt.

Falls ihr eine Umfrage zur Vsync-Nutzung macht würde mich gleichzeitig noch interessieren, welche Displays dabei benutzt werden.

[FlashBFE]

Ich frage mich auch, wo dieses Adaptive VSync nun der große Heilsbringer ist. Das kann doch nur da hilfreich sein, wo TB nicht funktioniert. Da wäre es mir aber lieber gewesen, wenn TB komplett und immer funktionieren würde. Es scheint ja, wie einige hier schreiben, bei Nvidia schon forciert zu werden, aber ich habe dummerweise eine AMD Karte ;-).

Ich habe mit der AMD Karte und aktiviertem Vsync sogar manchmal das Problem, dass der "Umbruch" dauerhaft an einer Stelle im Bild bleibt, was natürlich besonders nervig ist. Es wäre mal schön, wenn so eine grundlegende Funktion wie VSync mit TB endlich mal universell und fehlerfrei arbeitet. Das kann doch nicht zuviel verlangt sein nach über 15 Jahren 3D-Grafikkarten?

[aufkrawall]

Ich frage mich auch, wo dieses Adaptive VSync nun der große Heilsbringer ist. Das kann doch nur da hilfreich sein, wo TB nicht funktioniert. Da wäre es mir aber lieber gewesen, wenn TB komplett und immer funktionieren würde. Es scheint ja, wie einige hier schreiben, bei Nvidia schon forciert zu werden

Kommt wirklich auf die Anwendung an.
Bei DX9 so gut wie immer (bei The Legend of Grimrock komischerweise bei mir nicht), bei DX10 kommt es auf die Anwendung an.


, aber ich habe dummerweise eine AMD Karte ;-).
Schon mal den D3DOverrider ausprobiert?

[Mr. Lolman]

Es scheint ja, wie einige hier schreiben, bei Nvidia schon forciert zu werden, aber ich habe dummerweise eine AMD Karte ;-).

Ist bei AMD genauso.

[aufkrawall]

Ist bei AMD genauso.
Also hat der Vsync-Regler im CCC wieder einen Effekt?

[Mad-Marty]

Wenn, dann habe ich TB vergessen zu erwähnen. Wobei mir bei TB derzeit unklar, wo dieses aktiv ist - forcieren kann man es ja scheinbar nicht unter DX.

Das lässt sich mit dem DirectX Overrider vom Rivatuner überall forcieren (Vsync + TB), AMD + Nvidia, intel IGP vermutlich auch, weils in die DX calls eingreift.

Für die sturen Spielehersteller die immer noch keine solche Auswahloption im Spiel haben.
Wobei ich es in letzter Zeit kaum noch forcieren musste.

[Gast]

Adaptives Vsync ist in meinen Augen total schwachsinnig: Gerade bei niedrigen FPS-Raten sollte Vsync an sein, da hier das Tearing um so mehr auffällt.

Tearing fällt bei niedrigen FPS nicht weniger störend als bei hohen FPS, es ist viel mehr umgekehrt

Bis zum erreichen der Monitorfrequenz hat man genau eine Stelle die zerrissen wird. Erreicht die Framerate 2-fache Monitorfrequenz hat man immer 2 zerrissene Linien am Monitor, womit das ganze natürlich auffälliger wird. Bei noch höherer Framerate wird es natürlich noch schlimmer.

Es hängt natürlich noch von einigen weiteren Faktoren ab, wie auffällig das Tearing ist. Mit 60Hz ist jede Risslinie für 1/60s sichtbar, mit 120Hz nur mehr 1/120s, also wird das Tearing mit hoher Monitorfrequenz immer weniger wahrnehmbar. Fällt die Framerate unter die halbe Monitorfrequenz ist jedes 2. Bild am Monitor immer zwangsweise vollständig, tearing wird damit noch weniger wahrnehmbar.
Ist die erreichte Framerate nahe der Monitorfrequenz bzw. einem ganzzahligen Teiler oder Vielfachen wird die Risslinie immer in etwa in der gleichen Position erscheinen und damit natürlich tendenziell leichter wahrgenommen, als wenn die Framerate sich deutlich davon unterscheidet und damit die Risslinie am ganzen Monitor verteilt wird.

Den größten Einfluss hat wohl der Bildinhalt. So lange sich nichts bewegt kann es logischerweise auch kein Tearing geben. Bei Bewegungen in der Vertikalen fällt Tearing auch kaum auf, erst bei horizontalen Bewegungen wird es oft sehr deutlich, und bei Stroboskopeffekten wird es praktisch unübersehbar.
Hier hätte man auch einen guten Ansatzpunkt, wie man wahrnehmbares Tearing verringern könnte. Es gibt keinen vernünftigen Grund, warum unsere Monitore das Bild immer noch zeilenweise aufbauen müssen. Spätestens mit den neuen digitalen Schnittstellen wie Display-Port oder HDMI hätte man zumindest einen optionalen Modus hinzufügen können, in dem das Bild spaltenweise aufgebaut wird. Da ein Großteil der Bewegungen in Spielen in horizontaler Richtung stattfindet, könnte man damit das wahrgenommene Tearing schon deutlich reduzieren, ohne unbedingt VSYNC zu verwenden zu müssen.

Auch für Stereoskopie mit Shuttertechnik wäre das vorteilhaft, da die Shutterbrillen logischerweise so angesteuert werden, dass man in der Bildmitte möglichst die beste Stereotrennung hat. Am oberen und/oder unteren Rand wird es dann schlechter. Da wir aber heute üblicherweise Breitbildmonitore haben, wäre es weniger auffällig wenn sich diese "schlechten" Abschnitte am rechten und/oder linken Rand befinden würden.

Ansonsten muss ich mich dem allgemeinen Tenor anschließen. Sicher ist es nie verkehrt zusätzliche Features zu haben, aber dass das Adaptive VSYNC jetzt das non-plus-ultra ist kann ich nicht sehen und schon gar nicht, dass AMDs Treiberprogrammierer deshalb Kopfschmerzen bekommen sollen, da hat Nvidia beispielsweise mit PhysX oder oder 3D-Vision deutlich schlagkräftigere unique-selling-points.

Der Artikel macht eher den Eindruck, als wüsste der Autor nicht wirklich über die Funktionsweise von VSYNC bzw. das Zusammenspiel mit double- und tripple-buffer, sowie den Tearing-Effekt und wann bzw. warum dieser entsteht Bescheid.
Vor allem das gezeigte Diagramm erzeugt zweifel daran, dass sich der Autor wirklich mit der Materie beschäftigt hat. Adaptive-VSYNC bringt in diesem Beispiel nämlich praktisch gar nichts. Die Szenen in denen VSYNC aktiv ist lassen sich fast an einer Hand abzählen, man hat gegenüber regulärem VSYNC-OFF also nichts gewonnen.

Das Adaptive-VSYNC könnte eventuell dann sinnvoll sein, wenn die Framerate fast immer über der Monitorrefreshrate liegt und man kein TB verwenden will oder kann und mit A-VSYNC jene wenigen Fälle abfangen will, in denen die Framerate unter die Refreshrate fällt und den damit verbunden Sprung in der Framerate verhindern will.
Ein sinnvoller Einsatz wäre eventuell auch A-Vsync mit halber Monitorfrequenz, bei Verwendung eines 120Hz-Monitors, falls die erreichte Framerate üblicherweise zwischen 60 und 120FPS liegt.

Liegt die erreichte Framerate dagegen fast immer unter der Monitorfrequenz braucht es kein A-VSYNC, dann tut es VSYNC-OFF genauso. Bestenfalls der damit zwangsweise verknüpfte Framelimiter kann eventuell noch etwas zur Energieersparnis beitragen, wobei das aber auch nur auf der 680GTX wirklich interessant ist, da dort Frequenzen und Spannungen auch entsprechend angepasst werden.


Außerdem sind Shooter doch mit wechselndem Input-Lag (Vsync an/aus/...) auch nicht mehr wirklich spielbar.

Genau der wird ja mit Adaptive-Vsync verhindert bzw. ist nicht stärker als der unvermeidbare Anstieg des Input-Lags durch die geringe Framerate.

[Mr. Lolman]

Also hat der Vsync-Regler im CCC wieder einen Effekt?

Nö. Ich meinte Ingame VSync (das funktioniert ja).

[MadManniMan]

Arbeitet Adaptive VSync mit DB oder mit TB?

[aufkrawall]

Mit Sicherheit DB, da der TB doch gar nicht benötigt wird.

[MadManniMan]

Ja, klar! Danke! Denkblockade :D

Also behält man den üblichen Inputlag mit AVSync, den man ohne auf 60 fps hätte.

[Mr. Lolman]

Selbst wenns mit DB ist, hat man mindestens einen Frame Versatz. Anders kann das imo garnicht klappen.

[san.salvador]

Und wenns mit TB ist, dann ist es die Kombination der negativen Aspekte. :ugly:

[Gast]

Selbst wenns mit DB ist, hat man mindestens einen Frame Versatz. Anders kann das imo garnicht klappen.

Den hat man immer, schließlich sieht und reagiert man auf das gerade angezeigte Bild, während im Hintergrund immer das nächste Bild berechnet wird, ohne natürlich die Eingaben auf das gerade angezeigte Bild zu berücksichtigen.

[MadManniMan]

Selbst wenns mit DB ist, hat man mindestens einen Frame Versatz. Anders kann das imo garnicht klappen.

Wieso? Das nächste Frame wird "einfach" kurz zurück gehalten.

[gnomi]

OT: Einen Sinn sehe ich in adaptiven Vsync nur in dem Szenario, dass man zu 99% Fps >Hz-Limit (und damit Vsync an) hat und damit leben kann, dass in den restlichen 1% das Bild zerrissen wird.


Aber genau so stellt man sein Spiel performancetechnisch doch idialerweise ein. :confused:
60 fps+ in weit über 90% aller Fälle.
Das adaptive Vsync sorgt dann dafür, daß unvorhersehbare oder zu komplexe Szenen abgefedert werden und sich direkter steuern lassen.
Jetzt fehlt nur noch forciertes VSync für Zwischensequenzen in den Spielen.
Hier ist die Eingabeverzögerung völlig uninteressant, Tearing aber übel. (also VSync + TB)
Konsolenspiele wie Gears of War arbeiten schon lange mit derartigen Tricks, um die beste Spielbarkeit aus sogar nur 30 fps zu holen.
Und bei Rennspielen wie GT 5 oder Forza 4 arbeitet man mit 60 fps ingame und 30 fps in Replays.

[Döner-Ente]

Aber genau so stellt man sein Spiel performancetechnisch doch idialerweise ein. :confused:
60 fps+ in weit über 90% aller Fälle.


Wenn man die entsprechende Hardware hat, sicherlich :wink:.
Wenn ich allerdings vor der Wahl stehe a) 60+ Fps bei minimalen/mittleren Details und ohne AA oder b) <60 Fps, dafür aber max. Details+AA, entscheide ich mich für b.

[rafterman]

Das Ganze hat John Carmack bei der Rage Entwicklung ins Rollen gebracht. Im Rahmen der Zusammenarbeit mit den Treiberteams der Grakahersteller.

[Gast]

Also behält man den üblichen Inputlag mit AVSync, den man ohne auf 60 fps hätte.Nicht ganz. Der übliche Lag entsteht ja durch im Treiber forcierten Vsync, welcher bei NV wiederum in TB-Vsync resultiert. Beim adaptiven Vsync spart man den einen Frame Zusatzlag durch TB, weils ja adaptiv zwischen DB mit und ohne Vsync wechselt.

[BlacKi]

warum werden 120hz nie eingebunden wenn ein artikel geschrieben wird? gibt es vsync zwischen 60 und 120hz?

der bildschirm meiner schwester kann 75hz auch solche hz/fps zahlen werden nie berücksichtigt QQ

^^

vsync macht eh nur sinn über 30fps, untendrunter sollte man das deaktivieren...

[san.salvador]

warum werden 120hz nie eingebunden wenn ein artikel geschrieben wird? gibt es vsync zwischen 60 und 120hz?

der bildschirm meiner schwester kann 75hz auch solche hz/fps zahlen werden nie berücksichtigt QQ

^^

vsync macht eh nur sinn über 30fps, untendrunter sollte man das deaktivieren...
Bei dem "Artikel" fehlt so viel, da ist 120Hz schon unter ferner liefen.

[aufkrawall]

Tearing fällt bei niedrigen FPS nicht weniger störend als bei hohen FPS, es ist viel mehr umgekehrt

Bis zum erreichen der Monitorfrequenz hat man genau eine Stelle die zerrissen wird. Erreicht die Framerate 2-fache Monitorfrequenz hat man immer 2 zerrissene Linien am Monitor, womit das ganze natürlich auffälliger wird. Bei noch höherer Framerate wird es natürlich noch schlimmer.

Es hängt natürlich noch von einigen weiteren Faktoren ab, wie auffällig das Tearing ist. Mit 60Hz ist jede Risslinie für 1/60s sichtbar, mit 120Hz nur mehr 1/120s, also wird das Tearing mit hoher Monitorfrequenz immer weniger wahrnehmbar. Fällt die Framerate unter die halbe Monitorfrequenz ist jedes 2. Bild am Monitor immer zwangsweise vollständig, tearing wird damit noch weniger wahrnehmbar.
Ist die erreichte Framerate nahe der Monitorfrequenz bzw. einem ganzzahligen Teiler oder Vielfachen wird die Risslinie immer in etwa in der gleichen Position erscheinen und damit natürlich tendenziell leichter wahrgenommen, als wenn die Framerate sich deutlich davon unterscheidet und damit die Risslinie am ganzen Monitor verteilt wird.

Mein Eindruck ist ein anderer:
Je höher die fps sind, desto weniger lange ist das Tearing sichtbar.
Erscheint mir auch logisch, da ja schon viel schneller wieder neue Bilder dargestellt werden, die eventuell nicht mehr zerhackt sind.
Im Umkehrschluss hat man dann bei niedrigen fps-Raten länger die zerissenen Frames auf dem Schirm.


Ein sinnvoller Einsatz wäre eventuell auch A-Vsync mit halber Monitorfrequenz, bei Verwendung eines 120Hz-Monitors, falls die erreichte Framerate üblicherweise zwischen 60 und 120FPS liegt.

Was wäre damit denn besser als einfach eine 60 Hz Auflösung auszuwählen?
Dann kann man auch einfach wieder DB Vsync verwenden und kommt auf den gleichen Effekt.
Wäre allerdings eine Absicherung dagegen, dass wenn die fps doch mal unter 60 rutschen, man dann nur noch 30 hat.


Genau der wird ja mit Adaptive-Vsync verhindert bzw. ist nicht stärker als der unvermeidbare Anstieg des Input-Lags durch die geringe Framerate.
Ab 60fps hast du dann aber wieder den Input-Lag durch DB Vsync.
Der ist zwar nicht so stark wie bei TB, aber bei einigen Anwendungen würd der auch wieder nerven.

[BlacKi]

umso niedriger aber die fps umso mehr merkst du den framdropp.

ich pers. kann mich nie entscheiden was besser ist vsync an oder aus, beides nervt framedrop oder tearing.

hätte ich ne high end gfx card hätte ich vsync wohl an. aber bei bf3 stört das beim spielen wenn die fps von60 auf 30 oder manchmal von 30 auf 20 geht.

bei alten games ist vsync eh auf 120hz, und mehr fps brauch ich nicht, da spar ich strom/ reduziere wärmeproduktion

[Leonidas]

Bei nv ist TB in Dx immer forciert und nicht abschaltbar, wenn Vsync an ist. Bis auf ~4-5 Spiele klappt das.

Sry, aber wenn einem das neu ist, dann sollte man solche Texte vielleicht gar nicht erst verfassen, geschweige denn veröffentlichen.



Ja, mein Fehler. Muß ich ausbügeln. Hab mich zusehr vom HardOCP-Artikel begeistern lassen.

PS: Nachtrag steht an der Meldung dran, wird auch nochmal extra in den nächsten News erwähnt.

[aufkrawall]

Ein Merkmal von Qualitätsjournalismus ist, dass er sich auch mal korrigieren kann. (y)

[san.salvador]

Ein Merkmal von Qualitätsjournalismus ist, dass er sich auch mal korrigieren kann. (y)
Ein Merkmal von Qualitätsjournalismus ist, dass er sich immer korrigiert, wenn es nötig ist.

[aufkrawall]

Ein Merkmal von Qualitätsjournalismus ist, dass er sich immer korrigiert, wenn es nötig ist.
Stimmt, der kritische Maßstab ist angebracht.

[Gast]

Erscheint mir auch logisch, da ja schon viel schneller wieder neue Bilder dargestellt werden, die eventuell nicht mehr zerhackt sind.
Im Umkehrschluss hat man dann bei niedrigen fps-Raten länger die zerissenen Frames auf dem Schirm.

Da hast du einen Denkfehler. Wie lange die zerrissene Linie sichtbar ist hängt nur von der Monitorfrequenz ab, nicht von der Framerate. Die zerrissene Linie bleibt immer bestehen, bis der nächste Refresh sie wieder überschreibt.


Was wäre damit denn besser als einfach eine 60 Hz Auflösung auszuwählen?
Dann kann man auch einfach wieder DB Vsync verwenden und kommt auf den gleichen Effekt.

Bei 120Hz dauert ein Refresh nur 1/120s. Wenn also mal Tearing auftritt, weil die Framerate zu niedrig ist und VSYNC damit deaktiviert wird, ist es wesentlich weniger wahrnehmbar.


Ab 60fps hast du dann aber wieder den Input-Lag durch DB Vsync.
Der ist zwar nicht so stark wie bei TB, aber bei einigen Anwendungen würd der auch wieder nerven.

Den hast du immer und dieser ist auch nicht vermeidbar. Du siehst immer ein fertiges Bild, während gleichzeitig das nächste in einem anderen Buffer gerendert wird, würde man das nicht machen hättest du ständig ein Flackern am Monitor.

[Gast]

Wie soll man eigentlich bei der Umfrage abstimmen, wenn man sowohl bei TB als auch adaptivem Vsync Nachteile sieht? Beide dürften eine gleichhohe Kompatibilität aufweisen, aber TB hat als (leider im Artikel unerwähnten) Negativaspekt noch die Mikroruckler, und den adaptiven Vsync muss man per Intervall/2/3/4/usw. auf die niedrigsterwartete Framerate einstellen, um einerseits keine Mikroruckler (dank DB) und andererseits kein Tearing zu haben.

Sicher kann adaptiver Vsync ein sinnvolles Feature sein, ebenso wie TB. Aber, und dass bleibt leider meist unerwähnt, auch DB-Vsync ohne adaptive Deaktivierung kann eine sinnvolle Einstellung sein, die heutzutage seltener verfügbar ist als die in der Umfrage benannten Optionen...

[derF]

Ich würde zusammenfassend behaupten, dass es drei Fälle gibt:

1. Spiel ist nicht anfällig für Inputlag durch vS+TB: vS+TB an

2. Spiel leidet bei fps<Monitorrefresh und vS+TB unter störendem Inputlag: Adaptive vS an

3. Spiel leidet generell unter störendem Inputlag, der durch vS verstärkt/verursacht wird: vS aus, Framelimiter an

[Gast]

Da fehlt:

[x] Mir egal VS ist eh immer off

[FlashBFE]

Wie soll man eigentlich bei der Umfrage abstimmen, wenn man sowohl bei TB als auch adaptivem Vsync Nachteile sieht?

Das ist ja das eigentliche Problem: Jede Variante hat ihren nicht gerade kleinen Nachteil.

Am besten wäre wahrscheinlich die Kombination aus einem 120Hz Monitor, einer starken Graka für möglichst >>60fps und dazu Vsync mit TB. Dann wäre das Verzögerungs- und Mikrorucklerproblem nicht mehr so dramatisch.

Ich frage mich, warum die Grafikchipbauer nicht das Thema 120Hz viel stärker vermarkten. Die Spieler hätten einen echten Vorteil und die Hersteller hätten ne höhere Nachfrage nach starken Chips. :wink: Aber so lange selbst hier auf 3Dc für die meisten Spiele noch 45fps als "sorgenfreie Performace" angegeben werden, wird sich da so bald nichts ändern.

[aufkrawall]

Da hast du einen Denkfehler. Wie lange die zerrissene Linie sichtbar ist hängt nur von der Monitorfrequenz ab, nicht von der Framerate. Die zerrissene Linie bleibt immer bestehen, bis der nächste Refresh sie wieder überschreibt.
Ich habe es gerade mit fps-Limiter ausprobiert und es ist definitiv so, dass bei 120fps das Tearing deutlich weniger auffällt als bei 30fps.

[Gast]

Am besten wäre wahrscheinlich die Kombination aus einem 120Hz Monitor, einer starken Graka für möglichst >>60fps und dazu Vsync mit TB. Dann wäre das Verzögerungs- und Mikrorucklerproblem nicht mehr so dramatisch.Fast. 120Hz-Monitor, Framelimiter auf 61, Vsync mit DB. Dann hat man selbst dann, wenn ne heftige Szene kommt, noch 40fps ohne Mikroruckler oder Tearing.

[Leonidas]

Da fehlt:

[x] Mir egal VS ist eh immer off



Dafür ist nun ganz klar die vierte Option da. Du siehst keinen besonderen Praxisvorteil aus allen diesen Dingen und lebst mit Vsync=off.

[aufkrawall]

Die Umfrage wird sicherlich die allgemeinen Vorurteile wiederspiegeln.

[burninghey]

Habe mir den neuen Beta Treiber mit Adaptive VSync installiert. Das Feature funktioniert soweit ganz gut, dass ich jetzt (in Diablo 3) ab und zu auch mal 60 statt 30 fps habe. Allerdings habe ich nun bei aktiviertem VSync merkwürdige Lags, als wenn kurzzeitig der Charakter im Schlamm steckt (sich merklich langsamer bewegt).

Vsync habe ich bisher nie gebraucht, in Diablo 3 sind mir die Bildfehler bei deaktiviertem VSync das erste Mal störend aufgefallen.

edit: Triple Buffer im Treiber deaktiviert, in Diablo 3 keine Einstellmöglichkeit.

[san.salvador]

Bei nVidia kann man für Dx TB nicht deaktivieren.

[aufkrawall]

Bei nVidia kann man für Dx TB nicht deaktivieren.
Doch, bei Diablo III ist auch bei treiberseitigem Vsync der TB aus.
Das heißt aber nicht, dass man deshalb jetzt das adaptive braucht, der D3DOverrider funktioniert wunderbar.

[san.salvador]

Doch, bei Diablo III ist auch bei treiberseitigem Vsync der TB aus.
Das heißt aber nicht, dass man deshalb jetzt das adaptive braucht, der D3DOverrider funktioniert wunderbar.
Ich meinte, dass man im nV-Treiber TB nicht ausschalten kann. Es gibt zwar einen Schalter, der gilt aber nur für OpenGL.
Wenn man Vsync im Treiber aktiviert, erzingt der Treiber unter Dx immer TB. Ich meinte darum ging es.

[aufkrawall]

Ups, deine vorige Aussage macht Sinn. :D

[Mad-Marty]

Eigentlich fehlt hier noch eine Kombination.
Ich persönlich finde MSIAfterburner FPS Limiting @ 50 fps + TB als eine gute Lösung wenn in diversen Spielen keine 60 FPS gehalten werden können.

Ja klar ist da input Lag dabei, aber wesentlich schlimmer wäre der Drop auf 30 FPS.
Wobei mir das wie gesagt nicht so störend auffällt, bis auf ganz wenige Spiele, vornehmlich shooter wenn doch mal störend.

Quake3A wäre z.b. ein beispiel was ich nie mit VSync spielen würde.

Generell ist das aber ein Feature, was im Gesamtmarkt völlig unbedeutend ist,
die meisten haben schon zu tun AA & AF zu verstehen, den leuten kann man AVSync garnicht erklären.

Vielleicht wäre es aber doch viel besser,
wenn die Monitore einen variablen Refresh hätten.
Sollte doch für Panels kein Problem sein, sich variabel bis zum Max Hz upzudaten.

[MadManniMan]

So ... habe jetzt mehrfach mäßige Erfahrungen mit AVSync gemacht:

- generell sehr schön, kein zerrissenes Bild zu haben
- aber: heftiges Stottern im Bereich knapp UNTER 60 fps, wenn sich der Treiben nicht entscheiden kann, ob VSync jetzt an soll, oder nicht
- und: fühlt sich ein wenig nach Inputlag an :| kann das sein?

[aufkrawall]

- und: fühlt sich ein wenig nach Inputlag an :| kann das sein?
Wenn du die Refreshrate erreichst, ist halt wieder (wohl DB) Vsync an, das je nach Anwendung auch nen großen Input-Lag verursachen kann.

[MadManniMan]

Da ich bisher immer auf VSync verzichtet habe, das also quasi mein erstes Mal ist (ich bin ja so aufgeregt!), hat mich das ziemlich irritiert - auch bei Double Buffering ist ein gewisser Inputlag also normal?

[y33H@]

Japp.

[MadManniMan]

OK, das ist alles ziemlich mies. Also hoher Inputlag durch 1) weniger FPS, 2) einen Frame Versatz und 3) Ruckeln am Schwellenwert ;(

Wie schlimm dann wohl erst Triple Buffering mit einem weiteren Frame Versatz sein muss? :eek:

[aufkrawall]

Wie schlimm dann wohl erst Triple Buffering mit einem weiteren Frame Versatz sein muss? :eek:
Ich seh die Aufgabe von TB Vsync eher darin, dass wenn es mal kurz unter 60fps geht, der Einbruch abgefedert wird.
Aber nicht, dass man ständig mit weniger als 60fps rumdümpelt.
Kannst ja mal mit dem D3DOverrider und TB/DB rumprobieren...

[MadManniMan]

Natürlich geht es beim TB um das Lindern der DB-Problematik - aber um den Preis eines weiteren Frames Lag? Ich hätte es nicht für so problematisch gehalten, aber ich scheine recht empfindlich auf Lag zu reagieren ;(

[aufkrawall]

Natürlich geht es beim TB um das Lindern der DB-Problematik - aber um den Preis eines weiteren Frames Lag? Ich hätte es nicht für so problematisch gehalten, aber ich scheine recht empfindlich auf Lag zu reagieren ;(
Mit welcher Anwendung testest du denn?
Gibt da enorme Unterschiede.

[MadManniMan]

Mit welcher Anwendung testest du denn?
Gibt da enorme Unterschiede.

Momentan spiele ich eigentlich nur Left 4 Dead 2 an Shootern regelmäßig, aber selbst bei diesem recht gemächlichen Zock hat es echt weniger Spaß gemacht.

[aufkrawall]

Jo, die Source-Engine geht mit Vsync gar nicht, auch nicht nur mit DB.
Da spiel ich auch lieber ohne.

Frostbite- oder Cryengine bleiben aber selbst mit TB relativ direkt und bei RPGs, RTS', Rennspielen usw. spielt der Input-Lag häufig gar keine Rolle.

[InsaneDruid]

OK, das ist alles ziemlich mies. Also hoher Inputlag durch 1) weniger FPS, 2) einen Frame Versatz und 3) Ruckeln am Schwellenwert ;(

Wie schlimm dann wohl erst Triple Buffering mit einem weiteren Frame Versatz sein muss? :eek:

Es gibt keinen weiteren Frame Versatz bei TB. DIe beiden Backbuffer laufen nicht seriell.

[Gipsel]

Es gibt keinen weiteren Frame Versatz bei TB. DIe beiden Backbuffer laufen nicht seriell.
Ja, so sollte es sein (zumindest wenn man klassisches triple buffering macht, die DirectX frame queues können aber sicher auch anders konfiguriert werden, das ist die Aufgabe der jeweiligen Engine).
Deswegen hat man mit TB + VSync optimalerweise alle Vorteile von DB mit adaptiven VSyncs und zusätzlich kein Tearing unter 60Hz (was bei nVs adaptiven VSync im Prinzip dort auftreten kann) sowie ein geringeres Inputlag (definiert als Zeit zwischen Start des Renderns eines Frames und seiner Anzeige am Display) bei/oberhalb 60Hz (also wenn die GPU schneller könnte aber auf 60Hz limitiert wird) als mit DB. Belegt halt Speicher für einen zusätzlichen Backbuffer und spart im Vergleich zu double buffering keinen Strom mit VSync (weil das Rendern der Frames vollkommen entkoppelt von der Anzeige frei durchläuft). Also rein von der Performancesicht würde ich das diesem adaptiven Kram vorziehen.

[MadManniMan]

OK, ich geb's auf. Ich begreife das heute nicht mehr und hoffe darauf, dass mein Feed-Reader mir irgendwann mal einen Artikel mit dem Titel "VSync in Depth!!!111" entgegen schreit ...

[aufkrawall]

Ja, so sollte es sein (zumindest wenn man klassisches triple buffering macht, die DirectX frame queues können aber sicher auch anders konfiguriert werden, das ist die Aufgabe der jeweiligen Engine).
Deswegen hat man mit TB + VSync optimalerweise alle Vorteile von DB mit adaptiven VSyncs und zusätzlich kein Tearing unter 60Hz (was bei nVs adaptiven VSync im Prinzip dort auftreten kann) sowie ein geringeres Inputlag (definiert als Zeit zwischen Start des Renderns eines Frames und seiner Anzeige am Display) bei/oberhalb 60Hz (also wenn die GPU schneller könnte aber auf 60Hz limitiert wird) als mit DB.

Ich empfinde den Input-Lag mit TB definitiv etwas höher als mit DB, obwohl es ohne Vsync mit 300fps läuft.


Belegt halt Speicher für einen zusätzlichen Backbuffer und spart im Vergleich zu double buffering keinen Strom mit VSync (weil das Rendern der Frames vollkommen entkoppelt von der Anzeige frei durchläuft). Also rein von der Performancesicht würde ich das diesem adaptiven Kram vorziehen.
Habs gerade mal gemessen: Mit TB Vsync verbraucht er genau wie mit DB ca. 100W weniger als ohne Vsync.
Die GPU-Auslastung ist ebenfalls identisch zwischen den beiden Modi und Speicher nicht der Rede wert.

Witzig: Vsync per D3DOverrider bekämpft das Spulenfiepen schlechter als spieleigenes/per Treiber.
Mal den Stromverbrauch messen. :D

[Gipsel]

Also, bei klassischem Triple-Buffering funktionieren die 3 Puffer gerade nicht wie eine Queue (bzw. FIFO). Man hat einen Front-Buffer (der gerade angezeigt wird) und 2 Backbuffer. Die Engine rendert jetzt immer abwechselnd in die beiden Backbuffer (also im Zweifelsfall mit sehr viel mehr als die Refreshrate, VSync spielt da keine Rolle). Beim Bufferflip (also dem Refresh des Displays) wird der Backbuffer mit dem Frontbuffer getauscht, in den gerade nicht gerendert wird, der also das letzte fertig gerenderte Bild enthält (bei double buffering hält man mit VSync das Rendern schlicht an). Insbesondere bei dem früher meist an die Framerate gekoppelten Updates der Spielwelt erhält man mit TB + VSync die höchste "interne" Refreshrate (die gleiche wie ohne VSync) und damit den geringsten Inputlag mit dem Vorteil, daß man kein Tearing hat.

Die Aussagen in meinem vorigen Post sind natürlich vereinfacht (und stimmen auch nicht in jedem Fall). Für den fühlbaren Input-Lag spielt wie auch schon von anderen bemerkt die Engine eine große Rolle, nämlich wie genau dort die Änderungen in der Spielwelt geupdatet und dann gerendert werden und wie die frame flip queue (keine Ahnung, wie das bei DX offiziell heißt und bin zu faul zum Nachsehen) konfiguriert ist. Da kann man im Zweifelsfall einiges verbocken (was aber natürlich eigentlich nicht passieren sollte), was den Unterschied zwischen Engines erklärt.

[Gipsel]

Habs gerade mal gemessen: Mit TB Vsync verbraucht er genau wie mit DB ca. 100W weniger als ohne Vsync.
Die GPU-Auslastung ist ebenfalls identisch zwischen den beiden Modi und Speicher nicht der Rede wert.Was daran liegt, daß viele Spiele heutzutage kein wirkliches triple buffering mehr machen, sondern die 3 Puffer wie einen FIFO/eine Queue handhaben. ;)
Das senkt dann den Stromverbrauch auf Kosten des Inputlags.

[aufkrawall]

Was daran liegt, daß viele Spiele heutzutage kein wirkliches triple buffering mehr machen, sondern die 3 Puffer wie einen FIFO/eine Queue handhaben. ;)
Das senkt dann den Stromverbrauch auf Kosten des Inputlags.
Ist mit dem D3DOverrider auch so.
Welches Spiel soll den noch "echtes" TB haben?
Wenn man bei vielen OpenGL-Spielen den TB über den Treiber erzwingt, wird es auch furchtbar lahm.

[Gipsel]

Ich kenn' ehrlich gesagt keins. :D

[wn612953]

OK, ich geb's auf. Ich begreife das heute nicht mehr und hoffe darauf, dass mein Feed-Reader mir irgendwann mal einen Artikel mit dem Titel "VSync in Depth!!!111" entgegen schreit ...

Siehe beispielsweise:

Triple Buffering: Why We Love It

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


;)

Was daran liegt, daß viele Spiele heutzutage kein wirkliches triple buffering mehr machen

Und warum nicht?

[Gipsel]

Und warum nicht?
Weil die Developer das einbauen müssen und DirectX das out-of-the-Box nicht macht? Schau Dir mal das Update vom Artikel auf Anandtech an. ;)

Um das "klassische" Triple Buffering hinzubekommen, muß man in der Bufferqueue nach Beendigung des Renderns des dritten Buffers den zweiten verwerfen (wodurch der gerade beendete zum zweiten wird und man wieder einen leeren dritten hat). Müßte meiner Meinung nach auch mit DX gehen (aber das weiß Coda wohl besser), macht aber glaube ich kaum einer.

[wn612953]

Weil die Developer das einbauen müssen

Und wäre das so viel komplizierter :D;)?

und DirectX das out-of-the-Box nicht macht

Und was ist damit:

Wenn man bei vielen OpenGL-Spielen den TB über den Treiber erzwingt, wird es auch furchtbar lahm.


;)?

[MadManniMan]

Siehe beispielsweise:

(...)

;)

Ah! Es gab ein Update!

Genau so etwas habe ich befürchtet ... jetzt braucht's nen Praxis-Roundup. Die Theorie ist schön und gut wenn wir nicht sicher sagen können, was wann welche Auswirkungen hat ;(

[Gipsel]

Im Prinzip kann sich eine Engine sein Framelimit/adaptives VSync auch selber basteln und dabei die frame queues auch flexibler managen als die einfachen Varianten double/triple buffering bzw. FIFO frame queue mit VSync on/off. Ob das jemand macht und wenn nicht warum nicht, kann ich aber nicht beantworten (man scheut den Aufwand und das Tuning, um da eine wirklich gute Lösung hinzubekommen?). Da müßte man mal die hauptamtlichen Entwickler hier im Forum fragen ;). Aber prinzipiell sollten da bessere Lösungen möglich sein, als das, was der Teiber nachträglich machen kann (weil man z.B. das Gamestate-Update mit einbeziehen kann).

Klassisches Triple-Buffering erkennt man am höheren Stromverbrauch mit aktivem VSync, wenn man im Refreshrate-Limit hängt (sollte praktisch genau so hoch sein wie ohne VSync). Und wie aufkrawall schon festgestellt hat, kommt das heutzutage wohl eher selten vor.

[wn612953]

Ob das jemand macht und wenn nicht warum nicht, kann ich aber nicht beantworten (man scheut den Aufwand und das Tuning, um da eine wirklich gute Lösung hinzubekommen?).
Daher ja die Frage ob das überhaupt ein großer Aufwand wäre?

Und bei Middleware, wie CE3 oder UE3/UE4 beispielsweise, würden von diesem Aufwand doch automatisch auch gleich mehrere Spiele profitieren, oder?

am höheren Stromverbrauch mit aktivem VSync

Das könnte man doch aber weiterhin beispielsweise mit separatem Frameratelimiter verhindern, oder?

[Gipsel]

Das könnte man doch aber weiterhin beispielsweise mit separatem Frameratelimiter verhindern, oder?
Das würde dann unter die oben angesprochene Custom-Lösung fallen.
Man könnte z.B. versuchen, alles in der Engine so zu timen, daß ein gerendertes Frame möglichst nah vor dem nächsten Refresh fertig wird. Dann kann man sich die mit klassichem triple buffering dazwischen berechneten (und verworfenen) Frames im Prinzip sparen und minimiert gleichzeitig den Input-Lag im Vergleich zu einer simplen Frame Queue.
Das ist aber nicht ganz trivial, weil man ja im Prinzip die Renderzeit für ein Frame vorhersagen muß. Und die ist nunmal nicht immer konstant.

Und zu der Frage mit dem Aufwand: Nun, ich meinte ja, das wäre gut machbar. Und ob das wirklich so ist und ob es irgendwer so macht oder auch nicht, da muß man wie gesagt mal ein paar Entwickler fragen, nicht mich. ;)