Hallo zusammen,
textwall incoming. Aber was muss das muss
Hab ja auch ein bisschen Zeit reingesteckt.
Vorsichtshalber noch ne Markierung an
@gaussmath
Gut. Zum Thema.
Ich hab das CapFrameX Tool die letzten Tage etwas ausprobiert. Ersteindruck: absolut genial.
Nur habe ich mittlerweile starke Zweifel, dass die Werte auch nur ansatzweise korrekt sein können.
Vielleicht könnt ihr mich ja aufklären was und wie genau CapFrameX die Frametimes aufzeichnet oder ob ich hier einen Denkfehler habe (glaube ich aus meiner Überzeugung zwar nicht, aber jeder kann sich ja mal irren).
Ich habe den Verdacht, dass das was CapFrameX misst nicht mal ansatzweise etwas mit dem zu tun hat, was am Monitor ankommt.
Ich versuche das nachfolgend mal zu verdeutlichen.
Zuerst mein System:
i7 6700K mit 16GB 3200 MHz DDR4 und eine RTX3060ti.
Neueste Treiber, aktuellstes Windows, an einem Asus XG279Q (1440p Gsync Compatible zertifiziert mit 170 Hz)
Generell habe ich viele Spiele getestet und überall sehr ähnliche Ergebnisse bzw. das gleiche "Problem" mit CapFrameX.
Um aber Probleme mit CPU Bottlenecks, Bandbreiten und Streaming auszuschließen habe ich mich letztendlich entschieden die Werte von Ori and the Will of the Wisps zu nutzen, weil sie leicht reproduzierbar und analysierbar sind, das Spiel bei meinem Test keine Ressourcen nachladen muss und weil das Spiel in der getesteten Szene mit 160-170 FPS läuft. Hier liegt das CPU Limit.
Meine Testsequenz sieht folgendermaßen aus:
Ich bleibe hier nur auf der Stelle stehen und bewege mich keinen cm! Das ist der Test. 60 sec.
Hier im CPU Limit zu messen wäre natürlich diskussionswürdig. Schlechte Frametimes wären im CPU Limit nicht verwunderlich. Logisch.
Deswegen habe ich, um zu prüfen, ob die Frametimes, die mir CapFrameX präsentiert, korrekt sein können folgendes gemacht:
- Mein Display auf 60 Hz eingestellt und im Spiel im Monitor OSD geprüft, ob 60 Hz anliegen
- Im Spiel Vsync aktiviert + Gegencheck mit NVCP Vsync
- Zusätzlich nochmal mit Vsync + RTSS 60 FPS Limit getestet
- Die Tests mit GeForce Experience @ 60 FPS aufgezeichnet (die Aufnahme synct sich mit der Displayfrequenz)
- 240 FPS Aufnahmen vom Display mit meinem Smartphone erstellt.
Ein 60 sec. Test mit CapFrameX hat zu folgendem (extrem seltsamen) Ergebnis geführt:
Hier werfen sich einige Fragen auf. Aber ich liste mal auf:
1) Wie kann es möglich sein, dass trotz aktivem Vsync @ 60 Hz Frames mit einer Frametime kleiner 16,6 ms existieren?
Gäbe es wirklich solche Frames, dann würde sich das in Form von Tearing zeigen. Es MUSS sich in Form von Tearing zeigen und man würde das Tearing auch deutlich mit einer Slow Motion Videoaufnahme oder in einem Screencapture Video sehen. Ich habe beides gemacht und kein Tearing sehen können (was bei aktivem Vsync ja genau das ist, was man erwartet). Schalte ich Vsync aus, sehe ich es natürlich sofort sehr deutlich.
2) Ich habe sowohl das 60 FPS @ 60 Hz Vsynced Screencapture, als auch meine 240 FPS Slow Motion Aufnahme mit Smartphone Frame für Frame geprüft und ich sehe hier im Screencapture bei JEDEM einzelnen Frame eine Veränderung im Bild (gut sichtbar durch die ständigen Partikel Animationen im Spiel) Es gibt keinen einzigen doppelten bzw. "dropped" Frame, jeder Frame ist "unique". Auch die Slow-Mo Aufnahme bestätigt mir, dass zwischen jedem Bildwechsel die gewünschten 16,6 ms liegen und nichts anderes.
Die "physische" Prüfung bestätigt mir also, absolut perfekte 60 FPS mit 16,6 ms Frametimes bei dem jedes einzelne Frame einzigartig ist. Das ist das, was mir das Display wirklich zeigt! Dafür würde ich meine Hand ins Feuer legen.
Wie erklärt sich nun der wilde CapFrameX Verlauf? Das ergibt für mich leider absolut keinen Sinn.
Spätesten eine Frametime, die 49.8 FPS entspricht, sollte sich in mehreren dropped Frames bei 60Hz Vsync äußern, was man in der Videoaufnahme eben daran sehen würde, dass mehr als ein Frame in Folge identisch ist bzw. dass ein Frame nicht 16,6 ms sondern 33,3 ms oder 50 ms lang angezeigt wird (ein display-refreshzyklus, zwei oder drei usw. Mit Vsync ist das ja mehr als deutlich)
Ich halte es für absolut ausgeschlossen, dass der Wert von CapframeX korrekt ist. Zumindest es es nicht das, was am Display angezeigt wird.
3) Auch ein zusätzliches 60 FPS Cap mit RTSS (welches für das außerordentlich gute Framepacing bekannt ist) hat an dem CapFrameX Graphen absolut NICHTS verändert.
4) Auch G-Sync (Vsync off) und RTSS @ 60 FPS limit ändern praktisch nichts an den Frametimes von CapFrameX
Entweder verstehe ich den Sinn von CapFrameX nicht oder ich muss hier tatsächlich anzweifeln, ob die Werte korrekt sind. Wie gesagt: Wenn ich am Display exakt alle 16,6 ms einen neuen Frame präsentiert bekomme. Dann kann/sollte hier nichts anderes als eine waagrechte Linie angezeigt werden.
Und nur ums nochmal klar zu machen. Hier geht es um Frametimes. Ich habe hier nichts anderes als Framtimes gezählt und gemessen. Dass FPS hier keinerlei Aussagekraft haben ist natürlich logisch. Dass generell Frametime Spikes oder ungerade verläufe exisitieren bzw. völlig normal sind weiß ich auch. Da werdet ihr mir nichts neues erzählen können. Darum gehts mir auch nicht.
Nur wenn das Display alle 16,6 ms einen neuen Frame zeigt, dann ist das erste, was ich mit 100%iger Sicherheit sagen kann, dass der Framtimegraph nur eine waagrechte Linie sein KANN. Und genau das ist dann eben auch der Punkt an dem ich vergleichen kann, ob die Werte von CapFrameX plausibel sind oder nicht. Und scheinbar sind sie das nicht.
Da stellt sich natürlich die Frage, was CapFrameX hier überhaupt misst. Kann ja durchaus plausibel sein oder per software nicht besser realisierbar. Nur stelle ich mir dann die Frage, was so eine Messung aussagt. Im Endeffekt zählt doch das, was am Display ankommt.
Schlussendlich sei noch gesagt, dass das hier kein Angriff auf die eigentlich tolle Arbeit sein soll.
Ich will verstehen, was hier vor sich geht und das ganze hinterfragen und sollte ich recht haben dafür sensibilisieren.
Schließlich liegt hier ja auch ne gewisse Verantwortung, wenn PCGH und auch andere Seiten das Tool für Messungen nutzen, die aber schlimmstenfalls gar nicht korrekt wären.