Mass Effect: Andromeda - PS4-Version und Xbox-One-Fassung im Vergleich: Auflösung, Bildwiederholrate, Tearing etc.

[Temeter]

Und ich sehe Tearing in den meisten Fällen nicht mal. Zumindest kriege ich diese krassen Versetzungen eigentlich nicht mehr, die scheinen sich fast immer über das ganze Bild zu ziehen.

[HerrRosa]

@Temeter

Double buffering kann dir den input-lag schon von technischer Seite her nicht verdoppeln.
Selbst eine hypothetische Wunderengine, welche dir das Berechnete sofort in ein Bild umsetzt und deine Eingabe sofort in den nächsten frame einbindet, würde durch double buffering bei 60fps <16.67ms<1fps keine Verdoppelung der Latenz erfahren.
Jetzt ist es aber so, dass in ausnahmslos jedem Spiel mehrer frames in der pipeline stehen bevor sie ausgegen werden.
Der Einfluss von double buffering oder tripple buffering (mit fqs =0) ist im Verhältniss unbedeutend.

Einen Unteschied merkst du erst, wenn das Vsync zugleich ein fps limit erzeugt, oder, wie bereits in meinen letzten Post erwähnt, eine hohe fqs beisteuert.
Hypothetisches Beispiel:
Würde die Anwenung mit 120 fps laufen und drei frames buffern, beträge die Latenz 24.9 ms.
Mit double buffer Vsync und nun gekappten 60fps, wären es 50ms + (0.1...16.66ms).

Apropos, CSGO (Source Engine) hat einen fürchterlichen input-lag in kombination mit Vsync, welcher jedoch mit RTSS fast gänzlich verschwindet.

Zur Holzhammer Methode ala double buffering bzw. tripple buffering samt RTSS fps limit, sei aber nur geraten, wenn die fps absolut stabil bei/über 60 fps gehalten werden können, da sonst eine Kappung auf 30 fps bzw. 33.3ms frame-time stattfindet.

[Temeter]

@Temeter

Double buffering kann dir den input-lag schon von technischer Seite her nicht verdoppeln.
Selbst eine hypothetische Wunderengine, welche dir das Berechnete sofort in ein Bild umsetzt und deine Eingabe sofort in den nächsten frame einbindet, würde durch double buffering bei 60fps <16.67ms<1fps keine Verdoppelung der Latenz erfahren.
Jetzt ist es aber so, dass in ausnahmslos jedem Spiel mehrer frames in der pipeline stehen bevor sie ausgegen werden.
Der Einfluss von double buffering oder tripple buffering (mit fqs =0) ist im Verhältniss unbedeutend.

Einen Unteschied merkst du erst, wenn das Vsync zugleich ein fps limit erzeugt, oder, wie bereits in meinen letzten Post erwähnt, eine hohe fqs beisteuert.
Hypothetisches Beispiel:
Würde die Anwenung mit 120 fps laufen und drei frames buffern, beträge die Latenz 24.9 ms.
Mit double buffer Vsync und nun gekappten 60fps, wären es 50ms + (0.1...16.66ms).

Apropos, CSGO (Source Engine) hat einen fürchterlichen input-lag in kombination mit Vsync, welcher jedoch mit RTSS fast gänzlich verschwindet.

Zur Holzhammer Methode ala double buffering bzw. tripple buffering samt RTSS fps limit, sei aber nur geraten, wenn die fps absolut stabil bei/über 60 fps gehalten werden können, da sonst eine Kappung auf 30 fps bzw. 33.3ms frame-time stattfindet.

Nur funktioniert das alles niemals so wunderbar, wie du gerade schreibst. Schau dir jeden echten Button->Bildschirm Test zwischen Vsync und kein Vsync an. Ich habe dort immer das gleiche gesehen, und in den meisten Spielen ist das auch gut fühlbar.

60fps is standardmäßig (kommt auch auf den Bildschirm an) vielleicht 50ms lag, selbst gutes Vsync bei 100+ms. CSGO sogar bei 120 bei double buffer, und 140 bei tripple buffer.

CSGO willst du übrigens so oder so mit uncapped frames spielen, weil das Spiel massiv von höheren FPS profitiert, selbst wenn diese weit über die Kapazität des Monitors rausgehen. Und beim Pixelgenauen Zielen ist jedes bischen Mauslag störend.

[HerrRosa]

60fps is standardmäßig (kommt auch auf den Bildschirm an) vielleicht 50ms lag, selbst gutes Vsync bei 100+ms.

Wie bereits geschrieben ist diese Erhöhung schon rechnerisch nicht möglich und ich vertraue Zahlen eher als einem Nocebo.

CSGO willst du übrigens so oder so mit uncapped frames spielen, weil das Spiel massiv von höheren FPS profitiert, selbst wenn diese weit über die Kapazität des Monitors rausgehen. Und beim Pixelgenauen Zielen ist jedes bischen Mauslag störend.

Sicher, da Abtastung der Maus und Tastatur jenseits der 60hz liegen und die pipeline der Source-engine sich schneller abarbeitet.

[Temeter]

Wie bereits geschrieben ist diese Erhöhung bereits rechnerisch nicht möglich und ich vertraue Zahlen eher als einem Nocebo.

Jep, deine Amateurrechnungen sind sicher nützlicher als hunderte Tests via optischer Sensoren und high FPS Kameras.

[HerrRosa]

Jep, deine falsifizierbaren Rechnungen sind sicher nützlicher als hunderte Tests mit tripple buffering und unbekannten fqs via optischer Sensoren und high FPS Kameras.

fixed

[Temeter]

Meinetwegen, aber hier z.B. gibts zahllose analysen mit verschiedenen Framerates und Double/Tripple:

https://www.youtube.com/user/xFPxAUTh0r1ty/videos#

Ich mein, keine Ahnung warum das soviel Lag versacht, die hohen Zahlen hatte mich auch völlig überrascht, obwohl sich Spiele mit Vsync für mich oft falsch anfühlten. Technisch gesehen sollte es schneller gehen, aber GPUs sind halt komplex.~

Müssen halt wir warten, bis Zeugs wie Gsync/FreeSync/FastSync richtig ausgereift sind. Bis dahin ists halt Frage der persönlichen Vorzüge und eventuell bessere Implementierung von Sync. Oder 144fps, die reduzieren Tearing und Lag.

[HerrRosa]

https://www.youtube.com/user/xFPxAUTh0r1ty/videos#

Schöner Kanal, welcher übrigens mein Geschreibsel bestätigt.


https://www.youtube.com/watch?v=rs0PYCp ... OT5sJ0vWy8

Wie man sieht, erhöht Vsync in Kombination mit einem fps limit die Latenz um ca 4-8 ms, was ca. der frame-time bei 144 fps entspricht.

Die Verdoppelung von 50ms auf 100ms spielt sich bei Battlefield ab, ohne RTSS, Angabe der Vsync Variante und fqs.

P.S.
Seine Aussage, den internen frame limiter zu verwenden, sollte nur teilweise beherzigt werden.
Das mag bei CSGO und Overwatch stimmen, aber schon bei the Witcher 3 zB. zerschießt einem der interne Regler die frame-times massiv. RTSS bildet eine gute Allzwecklösung, wenn sonst nichts geht.
Auch sollte man, anders als im Video dargestellt, die fps nicht unter die Kappung setzten sondern genau drauf.
Der gegebenenfalls zusätzliche frame wiegt leichter als permanentes micro Ruckeln.

[Temeter]

Jup, mit Gsync und Cap direkt unter max hz kannst du den Lag massiv reduzieren, davon wusste ich schon. Bin allerdings ehrlich erstaunt, wie gut RTSS funktioniert. (edit: Nvm, das hier ist RTSS + Gsync? Das ist natürlich was anderes)

Btw, mein grundsätzliches Argument steht noch: Bei 144hz Vsync hast du also immer noch 60% mehr lag. Wobei selbst das deutlich besser ausschaut, als bei den alten Tests. Vielleicht sind die Treiber und GPUs einfach besser geworden? Interessant.

Ich hatte mich auf Zeugs wie das hier bezogen, gerade mal 5 Monate alt:



Und da sind die Nummern für 60fps Vsync verdammt mies, und keinesfalls gut bei 120fps. Die Nummern für Overwatch um den Zeitraum waren sehr ähnlich btw.

[HerrRosa]

(edit: Nvm, das hier ist RTSS + Gsync? Das ist natürlich was anderes)

Der interresante Vergleich bezieht sich auf No Sync fps limit vs. Vsync fps limit. RTSS und Gsync sind erst mal wurscht.

Btw, mein grundsätzliches Argument steht noch:

Nur wenn du die fqs ignorierst

Ich hatte mich auf Zeugs wie das hier bezogen, gerade mal 5 Monate alt:

Show

Man sieht gut das double buffer Vsync mit einer fqs=5 daherkommt und tripple buffer seiner Funktionsweise entsprechend noch einen frame von 16ms draufsetzt.
Ich würde meine Hand ins Feuer legen, dass bei Vsync mit fps limit die durchschnittliche Latenz bei ca. 66ms liegen würde.

Zudem ist schön zu sehen, dass die engineeigenen Latenzen nur zum Teil fps abhängig sind.
Hinzu kommt noch Datenübertragung, Monitorlatenz, Pheripherieabtastungsrate etc.

Wie gesagt, selbst bei responsiven Engines ist die von vernünftigem Vsync verursachte Latenz im Vergleich vernachlässigbar.
Speziell bei single-player Spielen wie Mass Effect Andromeda.

[Temeter]

Ahso, hab mal gecheckt: PQS sind einfach vorgerenderte Bilder. Warum nicht 'prerendered frames', veraltete AMD Begriffe kennt ja keiner :^)

Ok, warum haben die so einen großen Einfluss? Sollten die bei Vsync deiner Theorie nicht nur einen frame hinzufügen? Warum fügt Vsynq 5 PQS hinzu? Das macht doch keinen Sinn.

Und wieso fügen dieselben Spiele dann bei Gsync plötzlich keine 5 PQS hinzu?

Wie gesagt, selbst bei responsiven Engines ist die von vernünftigem Vsync verursachte Latenz im Vergleich vernachlässigbar.
Speziell bei single-player Spielen wie Mass Effect Andromeda.

Noooooope. Du bist einfach nurn scrub

Ich start TW Battlefleet Gothic, Taktikspiel, aktivier Vsync, und kotz wegen der massiven laenz.

[HerrRosa]

Ok, warum haben die so einen großen Einfluss? Sollten die bei Vsync deiner Theorie nicht nur einen frame hinzufügen? Warum fügt Vsynq 5 PQS hinzu? Das macht doch keinen Sinn.

Die Idee dahinter war ja, dass das böse Vsync bei Nichteinhalten der benötigten fps jenseits der Kappung, und darauf, die fps von 60fps auf 30fps reduziert, von 30fps auf 20fps und von 20fps auf 15fps.

Dann kam tripple buffering, was nun einen zusätzlichen frame vorspeicherte, umso einen etwaigen frame drop zu kompensieren und durch einen schnellen "halb frame" ersetzte. Das sieht dann bei einem Einbruch auf 45 fps etwa so aus: 16ms-33ms-16ms-16ms....
Je mehr Bilder die GPU vorhalten kann, desto besser und länger funktioniert diese Technik, wohingegen die Latenz umso höher ausfällt. So entstanden dann Konzepte wie multiple buffering und darüber hinaus.
Es gibt zwar Spiele wie Far Cry 3, welche einen selbst einstellen lassen wie viele frames vorgehalten werden sollen, aber diese sind rar und in der Regel entscheidet die Engine/Treiber was Sache ist.

Wenn jetzt jedoch auf einmal ein fps limiter wie RTSS daherkommt und die fps genau auf 60fps setzt, zwinkt RTSS quasi die GPU wieder in das traditionelle tripple buffering, da die GPU nicht mehr "vorrechnen" kann.
Deswegen sollte man, wie ich bereits schrieb, Vsync + RTSS nur verwenden, falls man sich sicher ist, dass man das angestrebte fps Kapp auch halten kann. Bei reinem double buffering gilt diese Regel sowieso, da man sich sonst die fps effektiv halbiert.

Und wieso fügen dieselben Spiele dann bei Gsync plötzlich keine 5 PQS hinzu?

Weil es nicht mehr nötig ist. Bei einem etwaigen fps Einbruch muss nicht mehr die GPU einstecken, sondern der Monitor.
Bei einem frame drop von 60 fps auf 45fps sehe das dann so aus: 16ms-22ms-16ms-16ms...

Dadurch, dass die GPU nicht mehr vorhalten muss, ergibt sich, dass die Latenz von Freesync identisch ist mit der von no Sync bei gleichen fps.

[Temeter]

Ok, warum haben die so einen großen Einfluss? Sollten die bei Vsync deiner Theorie nicht nur einen frame hinzufügen? Warum fügt Vsynq 5 PQS hinzu? Das macht doch keinen Sinn.

Die Idee dahinter war ja, dass das böse Vsync bei Nichteinhalten der benötigten fps jenseits der Kappung, und darauf, die fps von 60fps auf 30fps reduziert, von 30fps auf 20fps und von 20fps auf 15fps.

Dann kam tripple buffering, was nun einen zusätzlichen frame vorspeicherte, umso einen etwaigen frame drop zu kompensieren und durch einen schnellen "halb frame" ersetzte. Das sieht dann bei einem Einbruch auf 45 fps etwa so aus: 16ms-33ms-16ms-16ms....
Je mehr Bilder die GPU vorhalten kann, desto besser und länger funktioniert diese Technik, wohingegen die Latenz umso höher ausfällt. So entstanden dann Konzepte wie multiple buffering und darüber hinaus.
Es gibt zwar Spiele wie Far Cry 3, welche einen selbst einstellen lassen wie viele frames vorgehalten werden sollen, aber diese sind rar und in der Regel entscheidet die Engine/Treiber was Sache ist.

Wenn jetzt jedoch auf einmal ein fps limiter wie RTSS daherkommt und die fps genau auf 60fps setzt, zwinkt RTSS quasi die GPU wieder in das traditionelle tripple buffering, da die GPU nicht mehr "vorrechnen" kann.
Deswegen sollte man, wie ich bereits schrieb, Vsync + RTSS nur verwenden, falls man sich sicher ist, dass man das angestrebte fps Kapp auch halten kann. Bei reinem double buffering gilt diese Regel sowieso, da man sich sonst die fps effektiv halbiert.

Dank dir für die ausführliche Erklärung! Ist das erste mal, das mir jemand tatsächlich mal erklären kann, warum Vsync so viel Lag verursacht.

Eins verstehe ich nur nicht: Du sagst, dass die GPU bei 60fps lock nicht vorrechnen kann. Warum das, Ich dachte, bei prerendered Frames geht es eher darum, Bilder zurückzuhalten?

edit: Oder meinst du, dass die GPU praktisch 'überflüssige Frames' in den Buffer schiebt? Aber würde das dann nicht das Frametiming versauen? Ich meine, die PQS können sich ja nicht von Frame zu Frame ändern?

Ich weiß, aber das ergibt so viele Fragen


btw: In Nvidia Treibern konnte man prerendered Frames auf 1 stellen. Bei AMD haben sie die Option wohl entfernt, ist aber per Registry änderbar. Lohnt sich das?

https://community.amd.com/message/26747 ... nt-2674785 (letzter Beitrag)

[Balla-Balla]

Sieht doch verdammt geil aus auf beiden Systemen. Die paar Probleme sind wohl zu vernachlässigen und mal wieder nur ein Thema für die üblichen Grafik und FPS Erbsenzähler.

Wenn ich mir überlege, was ich heute bekomme auf einer zwo, drei Hundert € Konsole und wie das noch vor wenigen Jahren aussah, dann bin ich einfach nur begeistert. Manche Leute beklagen eben auch, dass der goldene Löffel in Mund oder Nase nicht aus Platin ist, dass sie ihn nicht vom Staat geschenkt bekommen und ihn auch noch selbst aus der Schublade holen müssen.