Edit: D
ein später hinzugefügtes Beispiel habe ich jetzt erst gesehen...aber ich hatte es schon vorher widerlegt, denn dann würde der Monitor nie hinterherkommen die Frames darzustellen und es wüden sich immer mehr Frames ansammeln bis die Verzögerung gigantisch wird.
double buffer V-Sync hat ja aber immer nur bis zu zwei Frames im Buffer..keine 7...sonst würde es nicht "double" heißen und der Monitor hat keinen Buffer, der leitet das Signal gleich Zeile für Zeile auf das Display.
Sun_set_1 schrieb:
Aber meiner Meinung nach erklärt er es bei 6:10 sehr deutlich.
Er sagt der lag von input(Mausklick) zum display refresh(Ergebnis zeigt sich am Monitor, kann schnell mehr als 50ms sein.
Hat er ja auch recht mit, denn Battle(non)sense hat ja z.B. 52ms gemessen.
Da ist eben nicht nur die Zeit, die die GPU braucht drin, sondern auch das was die CPU berechnet und was der Monitor an Zeit braucht.
Mir geht es nicht darum das es insgesamt länger als 50ms dauern kann, das ist klar...mir geht es um den
Unterschied von V-sync off zu on.
Das habe ich doch vorher schon extra unterstrichen
.
Sun_set_1 schrieb:
Der minimale Inputlag ist immer 16,7ms bei VSynch.
An 16,7 kann man nie ran kommen bei einem 60Hz Monitor. Dann müsste ja alles vorher in 0ms fertig sein.
Aber ja, damit ist es der
minimal mögliche...nur irgendwie ist das nicht der Punkt weil es ja um den
Unterschied geht.
Denn wenn man sich den Beispiel-Ablauf anguckt, dann stellt man fest, dass es mit V-sync an zu einer zusätzlichen Wartezeit von 11,7ms bei einer GPU die 200FPS schafft(16,7ms-5ms) kommt.
Laut der Erklärung im Video sind diese 11,7ms der
Unterschied von V-sync off zu on.
Wenn der input lag vorher 52ms gewesen ist, sollten wir mit V-sync on bei 63,7ms landen. Oder wenn man versucht immer so gut wie möglich für den Angeklagten zu rechnen, eben 67,7ms(für den Fall das die GPU 100000FPS kann und den Frame sofort fertig hat.
Da fehlen immer noch einige zusätzliche ms bis man bei den gemessenen 124ms landet....wo diese auf der Strecke bleiben wird nicht beantwortet.
Sun_set_1 schrieb:
CPU des Monitor/TV benötigt um das Bild physikalisch zu rendern, kann das Ganze auch mal schnell auf 50ms steigen lassen
Wenn der Monitor länger bräuchte ein empfangenes Bild darzustellen als er für einen refresh Zeit hat, dann würden sich immer mehr Frames in einem nicht vorhandenen Zwischenspeicher des Monitors ansammeln.
Frame 1 kommt....nach 50ms ist der monitor fertig mit dem Bild und hat schon drei refreshs verpasst....also fängt er mit Frame 2 an, und sobald das dargestellt ist, liegen ja nur Frame 3, 4, 5 und 6 in der Warteschleife....
Mir ist klar, das die beworbenen 1-4ms der Herstellerangaben Blödsinn sind, aber sowas wie 12ms ist für einen 60Hz Monitor realistisch. Und diese ca 12ms sind ja da ob V-sync an oder aus ist......die
ändern sich ja nicht, nur weil der Monitor
vollständige und nicht
zerrissene Bilder darstellen muss....ist dem völlig egal.
Sun_set_1 schrieb:
Dann noch das Problem mit dem richtigen herauspicken der Frames, wenn die GPU 200fps berechnet. Das erklärt er ja zum Anfang schon. Der gegenteilige Effek.....
Keine Ahnung was das "richtige herauspicken" meint aber der ganze Absatz hat nichts mit dem Phänomen zu tun.
Bei 7:33 geht er auf den Unterschied im Input lag ein....Er sagt, das bei 200FPS auf einem 144Hz Monitor der Unterschied 5-7ms betragen kann. Das stimmt mit dem überein, was die Theorie voraussagt:
Der refresh dauer fast 7ms, Wenn das Bild super schnell fertig gerendert ist, erhöht sich der input lag um bis zu 7ms.
Später macht er Fehler, wenn er über CS GO redet.
Bei 7:68 sagt er der (absolute)input lag wäre bestenfalls bei 2,5ms und mit V-sync on 16,7ms
und mehr bei 60Hz.
Damit widerspricht er sich zu vorher, wo er von
bis zu 7ms (unterschied)bei 144Hz geredet hat und dann macht er noch den Fehler diesen
Unterschied als
vollständigen input lag zu betrachten und zu behaupten der input lag könne beim Wechsel von 400FPS auf 60FPS auf das 6 fache ansteigen. Da rechnet er einfach die 16.7ms(60FPS) durch 2,5ms(400FPS) und kommt auf "6 mal mehr".
Ist aber in der Realität nicht wahr, denn wenn man von ca. 52ms(60FPS)
vollständigem input lag auf 38ms(400FPS) kommen würde, wären das nur 27% besser und nicht 600%.
Und all diese Unterschiede die er beschreibt sind immer unter 16,7ms weil er sich an die Theorie hält, wie V-sync angeblich funktioniert.
Dann erklärt er Fast sync/enhanced sync, wo der input lag zwischen V-sync off und V-sync on liegt....ja ok.
Und dann wird es interessant, weil er noch eine Folie von AMD zeigt, wo offenbar Messdaten den input lag für Overwatch zeigen und ohne V-sync 72,7ms, mit fast sync 84,7ms und mit V-sync 128,8ms gemessen wurden.
Das ist ebenfalls weit entfernt von der theorie, wo die Basis von 72,7ms nur auf höchstens 87ms(V-sync on) hätte anwachsen dürfen.....scheinbar sind die Messwerte von Battlenonsense kein Einzelfall und an der Theorie stimmt etwas gewaltig nicht.
Bei der AMD Folie werden es nur 56ms in Overwatch mehr, bei Battle(non)sense 72ms mehr.
Und da gehen mir einfach die Ideen aus.
Funktioniert das Vorgehen der GPU mit front und backbuffer so wie in der Theorie, erklärt das ja nur bis zu 16,7ms. Es bleiben also noch grob 40ms in Overwatch und 56 in CS GO zu finden.
Es erscheint logisch, das eine GPU normalerweise weiß, wann sie grob mit dem rendern fertig sein wird, und schon frühzeitig nach neuen Daten fragt, damit sie gleich loslegen kann, sobald sie mit dem alten Frame fertig ist.
Wenn das bereitstellen der Daten durch die CPU länger braucht als die GPU zum rendern, kommen wir in ein CPU limit. Da die CPU offensichtlich mehr FPS kann, kann das bereitstellen eigentlich nur ca 5ms brauchen.
Das eigentliche Spiel sollte seinen eigenen Timer haben und nicht wie zu Pentium 1 Zeiten an die FPS gekoppelt sein...die Maus arbeitet unabhängig und der Monitor arbeitet unabhängig.
Wo kommt also jetzt die restliche Verzögerung her....ich habe nichtmal den Hauch einer Antwort gesehen.
Es reicht nichtmal, wenn man davon ausgeht, dass die GPU, die CPU schon für 2 Frames in die Zukunft nach Daten fragt, der einzelne Drawcall also schon länger dauert und dann die GPU schon am nächsten Frame arbeiten würde bevor der alte fertig ist.
Selbst dann dürfte sich der input lag nicht mal ansatzweise verdoppeln. Denn sonst wären wir entweder wieder in CPU oder GPU limit, was wir nicht sind.
) architektur und verkündet: "jaaa, also wir sind doch wieder dabei"
.
.
