PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Umfrage-Auswertung: Kann nVidias Adaptive VSync ein nutzvolles ...


Leonidas
2012-04-30, 08:39:18
Link zur News:
http://www.3dcenter.org/news/umfrage-auswertung-kann-nvidias-adaptive-vsync-ein-nutzvolles-feature-sein

Knuddelbearli
2012-04-30, 09:02:47
ich fidne nach wie vor deinen artikel und auch die umfrage fehlerhaft

geringerer inputlag ist zwar schön und gut dafür hat man massiv schwankenden inputlag wann imemr man die 60 fps über oder unterschreitet das ist 100mal schlimmer

aufkrawall
2012-04-30, 09:21:43
Ich glaube auch, dass die meisten Umfrage-Teilnehmer entweder gar nicht wirklich wissen, welcher Vsync-Modus im Endeffekt was bewirkt, und zudem auch noch von dem ganzen Pressewirbel um das adaptive Vsync beeinflusst sind.

Knuddelbearli
2012-04-30, 09:54:36
jap und da Leonidas direkt vor der umfrage selber einen titel pupliziert hat muss er sich da selber an die nase fassen ...

myMind
2012-04-30, 11:40:42
ich fidne nach wie vor deinen artikel und auch die umfrage fehlerhaft

geringerer inputlag ist zwar schön und gut dafür hat man massiv schwankenden inputlag wann imemr man die 60 fps über oder unterschreitet das ist 100mal schlimmer
Wieso soll das schlimmer sein, als bei festen 15er, 30er, 60er Stufen? Leuchtet mir noch nicht wirklich ein.

Gast
2012-04-30, 11:51:53
geringerer inputlag ist zwar schön und gut dafür hat man massiv schwankenden inputlag wann imemr man die 60 fps über oder unterschreitet das ist 100mal schlimmer
Bei adaptivem VSync überschreitet man die 60fps auch nicht, unterschreiten tut man sie bei TripleBuffering genauso. Letzteres hat also immer geringfügig mehr Input-Lag.

Die optimale Lösung wäre denke ich TB optional beim adaptivem VSync mit aufzunehmen:

oberhalb von 60fps: Vsync on
zwischen 30-60fps: Vsync on + Triple Buffer
unterhalb von 30fps: Vsync off

Falls das umschalten zwischen Double und Triple Buffer on-the-fly möglich ist.

Knuddelbearli
2012-04-30, 12:38:14
weill bei konstantem inpuitlag man sich daran gewöhnt, wenn er sich dauernt ändert geht das nicht.

vergleich es mit einer zugfahrt

was ist angenehmer ein zug der dauernd zwischen 100 und 110 kmh wechselt oder einer der konstant 100kmh fährt?

natürlich wäre es besser wenn er konstant 110 fahren würde ( = kein inputlag ) aber ist eben nicht möglich )

samm
2012-04-30, 12:41:32
myMind: Die von dir genannten fixen Stufen von fps hast du nur bei DB-VSync, du hast zusätzlich einen Inputlag von mindestens 1 Frame. Bei TB-VSync hast du einen zusätzlichen Inputlag, aber keine der von dir genannten "Framerate-Stufen". Bei adaptivem VSync hingegen hast du schwankenden und insofern wesentlich nervenderen Inputlag abhängig von der Framerate: Keinen unter der Grenze, die durch die Bildwiederholrate gegeben ist, und danach den normalen VSync-Inputlag (wobei mir nicht klar ist, ob double- oder triple-buffered wird). Diese Fluktuation ist natürlich störender.

Knuddelbearli
2012-04-30, 12:47:06
super erklärt danke ^^

Neon3D
2012-04-30, 12:51:34
ich fidne nach wie vor deinen artikel und auch die umfrage fehlerhaft

geringerer inputlag ist zwar schön und gut dafür hat man massiv schwankenden inputlag wann imemr man die 60 fps über oder unterschreitet das ist 100mal schlimmer

ich finde den artikel & umfrage durchaus sehr interessant. ein schwankender inputlag ist nichts ungewöhnliches, denn wenn man online spielt, addiert sich sowieso der ping, welcher auch nie konstant ist, bei jeder eingabe hinzu. abgesehen davon ist auch die abtastfreuqenz über usb oder ps/2 nicht 100% konstant, was auch noch mal ein paar ms zum gesammten inputlag beitragen.

allerdings ist die auswertung der statistik nicht ganz korrekt. lenoidas schreibt "Damit ist TripleBuffering aber noch lange nicht geschlagen, denn auch dieses kommt kummulativ auf beachtbare Stimmenanteile: 16,4 Prozent sehen TripleBuffering vorn und wie gesagt 15,8 Prozent auf gleicher Höhe – zusammen sind dies runde 32 Prozent."

die 15,8% kann man genausogut den anhängern für das adapt. vsync zurechnen, weil es eben gleichwertig zum 3buffer ist. besser gewesen wäre, die 16,4% direkt mit den 48,1% befürwortern zu vergleichen und die 15,8% wegzulassen.

samm
2012-04-30, 12:57:21
Klar hast du recht, was Eingabegeräte und Monitor angeht: auch diese tragen einige ms zum Inputlag bei. Beim Monitor konstant, bei einer guten Maus kaum merklich und relativ konstant.
Aber: Lag in Online-Games durch Ping != Inputlag (auch wenn die Auswirkungen die gleichen sein *können* - ausser ich hab hier gerade einen Denkfehler).die 15,8% kann man genausogut den anhängern für das adapt. vsync zurechnen, weil es eben gleichwertig zum 3buffer ist.
Nein, ist es eben nicht. Bei üblichem VSync (egal ob TB oder DB) hast du, wie gesagt, immer Input-Lag, mit diesem tollen neuen Feature hast du gerade dann, wenn die framerate um die Bildwiederholrate herum pendelt, ständig switches zwischen (zusätzlichem zu den von dir genannten Quellen) Inputlag 0 und (zusätzlichem) Inputlag X.

myMind
2012-04-30, 14:16:04
myMind: Die von dir genannten fixen Stufen von fps hast du nur bei DB-VSync, du hast zusätzlich einen Inputlag von mindestens 1 Frame. Bei TB-VSync hast du einen zusätzlichen Inputlag, aber keine der von dir genannten "Framerate-Stufen".
Warum sollte das so sein?

Mir ist schon klar, dass ein dritter Puffer beim Umschalten der Puffer und in Situationen wo Ladeverzögerungen auftreten, gewisse Vorteile bringt. Aber wenn die Karte dauerhaft die Bildwiederholrate nicht hinbekommt, bleibt ja gar nichts anderes übrig als mit dem Pufferwechsel jeweils einen kompletten Frame zu warten. Womit sich die Framerate dann halbiert. Oder sehe ich da komplett etwas falsch?

Blackhand
2012-04-30, 14:56:55
So langsam habe ich ja den Eindruck, Leonidas formuliert das nur deswegen so contra-AMD, damit er als eiserner AMD-User Druck auf AMD ausüben kann, damit die das Feature gefälligst kopieren, damit er auch was davon hat.

Ansonsten wäre ein Artikel, der überhaupt erstmal die Vor- und Nachteile von TB und AVsync gegenüberstellt sinnvoller gewesen. Ich hab mich, da ich ja sowieso immer VSync aus habe, nicht mit dem HardOCP(?) Artikel befasst, der sich dem AVsync widmet. Vielleicht stehen da ja ein paar Takte dazu drin.

Aber so scheinen mir die Argumente bezüglich Inputlag ziemlich aus der Luft gegriffen und offensichtlich scheint diesbezüglich auch keinerlei Klarheit hier unter den Membern zu herrschen.

Und kann denn überhaupt eine nennenswerte Anzahl von Leuten von AVsync aus der Praxis berichten und vergleichen? Ist das denn für die älteren NV-Modelle auch freigeschaltet?

Ansonsten sind die Umfrageergebnisse ja nichts weiter als blose Einschätzungen von einem Feature, was für die meisten Leute nur auf dem Papier existiert.

samm
2012-04-30, 15:34:38
Aber wenn die Karte dauerhaft die Bildwiederholrate nicht hinbekommt, bleibt ja gar nichts anderes übrig als mit dem Pufferwechsel jeweils einen kompletten Frame zu warten.Du musst dich fragen, wer hier worauf wartet. Bei DB muss die Grafikkarte tatsächlich darauf warten, dass der Monitor das Bild ausgibt, bevor sie ein neues Bild in den backbuffer zu schreiben beginnen kann. Man kann also bei 60Hz Bildwiederholfrequenz 60, 30, 20, 15, ... fps haben.
Bei TB kann die Grafikkarte fröhlich vor sich hin rechnen und füllt alternierend die beiden backbuffers. Das aktuellste fertige Frame kommt dann in den Frontbuffer, sobald das dort befindliche Bild dargestellt wurde. Die resultierende Framerate ist also die gleiche wie ohne VSync.

Ansonsten wäre ein Artikel, der überhaupt erstmal die Vor- und Nachteile von TB und AVsync gegenüberstellt sinnvoller gewesen. (...) Ansonsten sind die Umfrageergebnisse ja nichts weiter als blose Einschätzungen von einem Feature, was für die meisten Leute nur auf dem Papier existiert.Stimmt schon... Erstmal müsste man wirklich *wissen*, wie diese neue VSync-Variante funktioniert, lags vermessen, und testen, wie sie sich anfühlt :)

Schnitzl
2012-04-30, 16:28:55
Ich glaube auch, dass die meisten Umfrage-Teilnehmer entweder gar nicht wirklich wissen, welcher Vsync-Modus im Endeffekt was bewirkt, und zudem auch noch von dem ganzen Pressewirbel um das adaptive Vsync beeinflusst sind.
völlig richtig, deshalb stimme ich z.B. auch nicht ab ;)

myMind
2012-04-30, 20:23:09
Du musst dich fragen, wer hier worauf wartet. Bei DB muss die Grafikkarte tatsächlich darauf warten, dass der Monitor das Bild ausgibt, bevor sie ein neues Bild in den backbuffer zu schreiben beginnen kann. Man kann also bei 60Hz Bildwiederholfrequenz 60, 30, 20, 15, ... fps haben.
Bei TB kann die Grafikkarte fröhlich vor sich hin rechnen und füllt alternierend die beiden backbuffers. Das aktuellste fertige Frame kommt dann in den Frontbuffer, sobald das dort befindliche Bild dargestellt wurde. Die resultierende Framerate ist also die gleiche wie ohne VSync.

Alles verstanden und entspricht auch genau meiner Vorstellung vom Sinn und Zweck des Tripple Bufferings. Aber der letzten Satz, ist aus meiner Sicht in Überlastsituationen (Grafikkarte rendert langsamer als 1/Bildwiederholfrequenz) eben nicht richtig.

Was passiert in folgender Situation:
- Puffer A wird gerade dargestellt
- Puffer B ist - sagen wir - zu 60% fertig, also "Überlast"
- Es ist 1/Bildwiederholfrequenz Zeit seit dem letzten Swap vergangen. Sync-Zeitpunkt erreicht.

Wenn ich das richtig verstehe wird bei TB der Puffer A noch einmal gezeigt, also ein altes Bild, und an Puffer B wird weitergearbeitet. Das neue Bild erscheint beim nächsten Swap nach 2 * 1/Bildwiederholfrequenz Sekunden (idR 30FPS).

Beim adaptiven VSync würde Puffer B geswappt werden, sobald er fertig ist. Das neue Bild erscheint eher auf dem Bildschirm und es kann früher begonnen werden Puffer A zu befüllen. Daraus resultiert die höhere Framerate als beispielsweise 30FPS.


Für mich ergibt auch folgendes beim derzeitigen Diskussionsstand noch keinen Sinn:
- "TrippleBuffering ist heute sowieso idR bei Direct3D aktiviert"
- "Die resultierende Framerate ist (bei TB) also die gleiche wie ohne VSync"
> Wie kann man dann die bei HARDOCP gezeigten (http://www.hardocp.com/article/2012/04/16/nvidia_adaptive_vsync_technology_review/2) Sprungkurven überhaupt aufnehmen? Das dürfte dann ja gar nicht möglich sein.


Für mich ist das alles immer noch sehr unklar. Prinzipiell halte ich die Idee nach wie vor für gut. Ob die Umsetzung gut gelungen ist, steht noch einmal auf einem anderen Blatt.

Gast
2012-04-30, 21:03:18
Was passiert in folgender Situation:
- Puffer A wird gerade dargestellt
- Puffer B ist - sagen wir - zu 60% fertig, also "Überlast"
- Es ist 1/Bildwiederholfrequenz Zeit seit dem letzten Swap vergangen. Sync-Zeitpunkt erreicht.

Wenn ich das richtig verstehe wird bei TB der Puffer A noch einmal gezeigt, also ein altes Bild, und an Puffer B wird weitergearbeitet. Das neue Bild erscheint beim nächsten Swap nach 2 * 1/Bildwiederholfrequenz Sekunden (idR 30FPS).

Du musst das über einen längeren Zeitraum betrachten. Nehmen wir wie in deinem Beispiel an, dass die Grafikarte es schaft in 1/60s 60% des Bilds zu berechnen:

Nach 1/60s: Puffer A wird angezeigt, Puffer B zu 60% fertig, Pufer C 0%
Nach 2/60s: Puffer A wird angezeigt, Puffer B zu 100% fertig, Puffer C 20%
Nach 3/60s: Puffer A 0%, Puffer B wird angezeigt, Puffer C 80%
Nach 4/60s: Puffer A 40%, Puffer B wird angezeigt, Puffer C 100%
Nach 5/60s: Puffer A 100%, Puffer B 0%, Puffer C wird angezeigt
Nach 6/60s: Puffer A wird angezeigt, Puffer B 60%, Puffer C 0% (hier geht's wieder von vorne los).

Somit musst du nicht immer 2/60s "warten" bis ein neues Bild kommt, und damit sind es mehr als 30fps.

FPS ist eben nur ein Durchschnittswert. Du kannst auch mit VSync und Double Buffering (fast?) jeden beliebigen FPS Wert ereichen wenn sich die Berechnungszeit der Bilder nur genug unterscheidet. Ist in der Praxis natürlich nur selten der Fall, deshalb is der Framverlauf aus deinem Link meisten bei 30 oder 60 FPS, aber eben nicht immer.

samm
2012-05-01, 00:01:13
Gast: Der clou ist eben auch, dass die Grafikkarte ständig rechnen und ausgeben kann, während sie bei DB Däumchen drehen muss, bis sie den backbuffer wieder benutzen darf.

Für mich ergibt auch folgendes beim derzeitigen Diskussionsstand noch keinen Sinn:
- "TrippleBuffering ist heute sowieso idR bei Direct3D aktiviert"Dazu weiss ich auch nicht mehr, das haben einige im entsprechenden Thread behauptet. Bliebe mir wie dir nichts anderes übrig als zu googlen, das Forum zu durchsuchen oder auf einen kundigeren Menschen zu warten ;)
- "Die resultierende Framerate ist (bei TB) also die gleiche wie ohne VSync"
> Wie kann man dann die bei HARDOCP gezeigten (http://www.hardocp.com/article/2012/04/16/nvidia_adaptive_vsync_technology_review/2) Sprungkurven überhaupt aufnehmen? Das dürfte dann ja gar nicht möglich sein.Die Adaptive-VSync-Kurve kann man sich erklären, dass eben irgendein VSync ab 60fps aktiv ist. Ich seh immer noch nicht den Vorteil/Unterschied zu einem fps-Limiter. Oder könnte man mit einem Limiter bei, sagen wir, 60fps bei 60Hz im ungünstigsten Fall dauerhaftes Tearing an der gleichen Stelle haben :freak: Sprich Limiter sollte man immer mit VSync kombinieren - wobei man mit VSync ohnehin auf die Refresh-Rate des Monitors limitiert ist... Ach :freak:, ist eh OT an dieser Stelle^^

Wie dem auch sei, die Sprünge bei den VSync-Diagrammen von HardOCP ergeben für mich auch wenig Sinn - mal überlegen. Angenommen DB: Dann müsste, wie vom Gast angetönt, nicht die Frametime auf fps umgemünzt sein, sondern ein gewisses Intervall betrachtet werden, sodass die Werte zwischen 20 und 30 oder 30 und 60 zustande kommen können. Angenommen TB: Dann müsste statt die Frames, welche die Grafikkarte berechnet (in den backbuffern gemessen) die Frametimes des frontbuffers wie bei DB gesagt über ein Intervall hin auf fps umgerechnet sein. Hm.

Vielleicht mal auf jemanden warten, der etwas mehr mit rendering zu tun hatte als ich^^ Coda oder Ailuros oder so vielleicht...?

myMind
2012-05-01, 09:23:47
Du musst das über einen längeren Zeitraum betrachten. Nehmen wir wie in deinem Beispiel an, dass die Grafikarte es schaft in 1/60s 60% des Bilds zu berechnen:

Nach 1/60s: Puffer A wird angezeigt, Puffer B zu 60% fertig, Pufer C 0%
Nach 2/60s: Puffer A wird angezeigt, Puffer B zu 100% fertig, Puffer C 20%
Nach 3/60s: Puffer A 0%, Puffer B wird angezeigt, Puffer C 80%
Nach 4/60s: Puffer A 40%, Puffer B wird angezeigt, Puffer C 100%
Nach 5/60s: Puffer A 100%, Puffer B 0%, Puffer C wird angezeigt
Nach 6/60s: Puffer A wird angezeigt, Puffer B 60%, Puffer C 0% (hier geht's wieder von vorne los).

Somit musst du nicht immer 2/60s "warten" bis ein neues Bild kommt, und damit sind es mehr als 30fps.

FPS ist eben nur ein Durchschnittswert. Du kannst auch mit VSync und Double Buffering (fast?) jeden beliebigen FPS Wert ereichen wenn sich die Berechnungszeit der Bilder nur genug unterscheidet. Ist in der Praxis natürlich nur selten der Fall, deshalb is der Framverlauf aus deinem Link meisten bei 30 oder 60 FPS, aber eben nicht immer.
Danke Gast für die sehr gute Erklärung. Das hatte ich so noch nicht verstanden. Das gegebene Beispiel passt zufällig sehr gut zu den Verläufen, die bei HARDOCP zu sehen sind.

Erstaunlich ist, dass der Pech-Fall in den bei HARDOCP gezeigten Kurven offenbar recht oft vorkommt. Ich habe ihn im Rechenbeispiel oben mal dick gemacht (Schritt 1 bis 4, 30FPS).
Der Gut-Fall mit mehr als 30FPS kommt in den Messungen hingegen relativ selten vor (Schritt 5 und 6, > 30FPS). Was man auch sieht, die gemessenen gemittelten Samplewerte erreichen den VSYNC-Off-Wert nicht. D.h. auch hier müssen 30er Werte dazwischen sein, die die Rate nach unten ziehen.