Die Frage ist inwiefern Verzögerungen relevant sind. Als relevant sehe ich Verzögerungen an, die vom Nutzer bemerkt werden und so sein Nutzungserlebnis einschränken; da wirst du mir sicher zustimmen.
Frame Metering scheint mir jedoch nicht relevant für den Inputlag zu sein, da es schlichtweg keine Berichte/Tests/Reviews gibt in denen bemängelt wurde Nvidia Karten hätten einen größeren Inputlag als AMD Karten. Es fällt scheinbar schlicht nicht auf und ist daher meiner Meinung, also subjektiver Ansicht, nach ein legitimes Mittel gegen Mikroruckler vorzugehen.
Diese schränken das Nutzungserlebnis ungleich stärker ein als ein Phänomen, welches nicht oder vielleicht sehr selten bemerkt wird; auch da wirst du mir wohl zustimmen.
Grundsätzlich würde ich schon zustimmen, was mich aber etwas "stört" ist die Verpauschalisierung.
Das Problem ist nämlich, der Mensch ist ein Gewohnheitstier. Heist, er gewöhnt sich an gewisse/viele Sachen recht schnell...
Wenn du die schnellst mögliche Hardware hast (in der ganzen Inputlag relevanten Kette), so wird man sich an den Umgang selbst gewöhnen. Somit liegt auch die Vermutung nahe, das jemanden klar auffällt, wenn sich an der Reaktionszeit etwas derart ändert. Dazu kommt, aktuell gibts diese Frameausgabeverzögerung ja bei NV quasi nur in Verbindung mit MGPU. Und MGPU hat per se, je nach GPU Anzahl eben ein erhöhtes Inputlag. Die absolute Zeit, wie es sich bemerkbar macht, sinkt aber mit der Anzahl der FPS. -> logisch.
Mal ein paar Beispiele, was ich damit meine:
- es gibt Leute, die spüren/merken Framedrops bei SGPU von 120 auf 60 FPS. -> das ist eine Frametimeverdopplung von im Schnitt ~8,33ms (120 FPS) auf ~16,67 (60 FPS). Heist also, der User spürt die Änderung der Frametimes von in dem Fall ~8,33ms.
- es gibt Leute, die spüren/merken das erhöhte Inputlag bei MGPU im Allgemeinen. -> sagen wir 60 FPS AVG ohne Betrachtung der "glatten" Bildausgabe und zwei GPUs und AFR. Heist also, durch AFR wird ein zweites Bild gleichzeitig Berechnet. Somit steigt das Inputlag um die Zeit des zweiten Bildes. 60 FPS = ~16,33ms. Somit erhöht sich dieses um ~16,33ms. (+ alles, was noch in der Inputlagkette reinspielt) Je nachdem, wie hoch der Rest absolut ist, können ~16,33ms schon eine ganze menge Prozent ausmachen. (genaue Werte hab ich dazu aber keine -> dürfte auch schwer zu messen sein)
Resümierend auf den Beispielen fällt mir also folgendes auf.
- Gesamtbild Frametimes sind quasi gleichbedeutend der Verzögerung beim Inputlag. Denn beides heist, eine Änderung am Bild wird spät(er) als gedacht sichtbar.
- einige Leute sind so Reaktionsschnell, dass ihnen Änderungen der Frametimes von ~8,33ms absolut auffällt.
- Wenn mich nicht alles täuscht, kann es durch Framemetering bei NV dazu kommen, dass fast bis zur "vollen Zeit des Frames" verzögert wird. Das heist, 60 FPS = ~16,67ms. Das folgende Frame kann fast bis zu ~16,67ms verzögert werden. Real wird die Zeit wohl irgendwo bei Rund der halben Framezeit liegen. (geschätzt) Also irgendwo zwischen ~8,33 und 16,67ms.
- Oben drauf kommt noch die allgemeine Erhöhung des Inputlags um das zweite Frame selbst, da die Berechnung des zweiten Frames ja schon gleichsam getätigt wurde.
Heist in Summe also, pauschal zu sagen, das fällt nicht auf, ist leicht daneben.
Denn absolut gesehen kann! Framemetering so stark verzögern, das wir über absolute Werte sprechen, die weit höher sind, als dass, was einigen Leuten definitiv und belegbar auffällt! Und genau den Punkt kreide ich (dir) hier an. Denkt man das ganze jetzt mal weiter -> 30 FPS = ~33,33ms, liegt die Verzögerung schon im Bereich von ~16,67-33,33ms. Das ist schon bis zu viermal höher, als der Frametimeunterschied beim Framedrop von 120 auf 60 FPS
-> meinst du nicht auch, das fällt definitiv auf!?
Ne ist klar, wenn die Daten und Aufzeichnungen stimmen sieht man bei AMD- CF ........ gar nichts, weil das Bild verworfen wird oder nur in geringer Zeilenhöhe ausgegeben wird -> Fakt!
Ich habe ab und an das Gefühl, dass hier einige überhaupt nicht verstehen was das Thema ist! Natürlich ist es wünschenswert, das weder das eine (AMD mit Problemen im Bereich tatsächliche Ausgabe der Bilder) noch NV ( Bis jetzt nur vermutet und nicht belegt eine verzögerten Ausgabe erfolgt) vorkommt.
Aber es so hinzustellen, dass fehlende Bilder besser sind wie leicht verzögerte, dass muss mir mal schnell jemand erklären das kapier ich jetzt gerade nicht
Es spricht doch niemand von besser oder schlechter...
Ich gebe dir vollkommen recht, das die Umsetzung aktuell nicht! optimal ist.
Ich sage aber auch, das eben ein Frameverzögern durch genannte Nachteile ebenso nicht optimal ist. Nur wird eben von so mancher Person hier im Forum die NV Lösung fast als der Heilige Gral gelobt
Und das ist unobjektiv ohne Ende.
Im übrigen finde ich die Ergebnise irgendwie auch etwas komisch. PCP und THG messen irgendwie dezent verschiedene Werte. Wärend bei THG das CF bei fast allen Tests! in den Practical FPS (der Wert ohne Runt und Dropped Frames) sehr sehr nahe am SLI dran ist, ist beim PCP Test das CF streckenweise nur auf Single GPU Niveau und deutlich! unter dem SLI. Obwohl beide Tests mit halbwegs gegenseitig vergleichbaren Gespannen testen.
Das wirft für mich die Frage nach der Messmethode auf. Denn scheinbar hängt es entweder massivst! an der Szene. Oder am Testsystem oder an sonstwedem anderen, was die Ergebnise beeinflusst.
Oder guck ich an der Stelle schief?
-> taugt aber bis dato in den zu sehenden Umsetzungen nur bedingt.
Ich habe einen 120Hz Monitor daher sollte wenn möglich die FPS nicht unter 120 fallen und eine verzögerte Ausgabe ist genauso schlimm, da ich ja im dümmsten Moment einen Gegner nicht sofort sehe, er mich aber evtl. schon. Heisst er hat "die Verzögerung" mehr Zeit als ich um zu visieren. Bei mir ist es aber nicht ganz so,(je nach Map)schlimm, da ich für Fahrzeuge zuständig bin und daher nicht jedes Frame sehen muss, wenn ein Inf vor mir rumturnt. Wenn aber etwas schnelleres Jet, Heli vor mir rumfliegt und dann noch eine gewisse Distanz dazu kommt die ich ja noch "berechnen" muss beim Schuss, dann ist es auch wieder wichtig, dass beides stimmt. 
