Hat hier jemand Erfahrungen gemacht mit Bans, die aufgrund des Tools ausgesprochen wurden? Habe einen VAC-PUBG-Ban erhalten heute komplett grundlos. Windows 10 ist neu und die einzigen beiden Programme die während des Spielens liefen bzw. aufgenommen haben, waren CapFrameX und msi afterburner in einer Beta Version.
Habe einen Bug entdeckt. Wenn man unter dem Reiter Comparsion auf "FPS" bei Values wechselt, bleibt die Legend oberhalb bestehen, auch wenn man sie deaktiviert. Erst wenn man den Range Slider aktiviert, merkt CX, dass die Legend eigentlich deaktiviert ist und lässt sie verschwinden. Version: 1.5.7 Beta Revision 5
Anhänge
.gif "sm_=) =)")
TE
TE
gaussmath
Guest
@PCGH_Dave Sauber entdeckt! Danke, werden wir mit der nächsten Version beheben.
@PCGH_Raff Wir haben in den letzten Monaten selbst viel gebencht und uns die Ergebnisse sehr genau angeschaut. Das Ziel war es, einen Fehlerbereich von 1% einhalten zu können, ohne auf das wertvolle Feedback durch das Overlay verzichten zu müssen. Mit dem neuen "Auto Overlay" Feature, ist das fast immer gelungen.
Außerdem hattest du irgendwann mal die Idee geäußert, dass tatsächlich nur jene Sensordaten ausgewertet werden, welche auch wirklich gebraucht werden. Das haben wir nun auch (in der Schublade). Eine neue interne Konfigurationsschicht, die sich durch den gesamten Code (UI bis runter zu den Telemetrieroutinen) zieht, macht das möglich. Mit einem reduzierten Set von Daten sinkt die CPU-Last damit auf um die 0.1%, wodurch man Sensorlogging nicht mehr wirklich abschalten muss. Das Overlay muss/sollte aber per "Auto Overlay" Option abgeschaltet werden, siehe folgendes Extrembeispiel.
@PCGH_Raff Wir haben in den letzten Monaten selbst viel gebencht und uns die Ergebnisse sehr genau angeschaut. Das Ziel war es, einen Fehlerbereich von 1% einhalten zu können, ohne auf das wertvolle Feedback durch das Overlay verzichten zu müssen. Mit dem neuen "Auto Overlay" Feature, ist das fast immer gelungen.
Außerdem hattest du irgendwann mal die Idee geäußert, dass tatsächlich nur jene Sensordaten ausgewertet werden, welche auch wirklich gebraucht werden. Das haben wir nun auch (in der Schublade). Eine neue interne Konfigurationsschicht, die sich durch den gesamten Code (UI bis runter zu den Telemetrieroutinen) zieht, macht das möglich. Mit einem reduzierten Set von Daten sinkt die CPU-Last damit auf um die 0.1%, wodurch man Sensorlogging nicht mehr wirklich abschalten muss. Das Overlay muss/sollte aber per "Auto Overlay" Option abgeschaltet werden, siehe folgendes Extrembeispiel.
TE
TE
gaussmath
Guest
Wir können euch nächste Woche sicherlich was geben, aber ohne ausgiebige Tests möchten wir keinen Release Status vergeben. Könnt ihr das denn vor dem Marathon ein paar Tage testen?
Ansonsten hat die aktuelle Beta 1.5.7 das Auto Overlay Feature bereits. Die F1 Runs oben sind damit gemacht worden. Die Lastoptimierung würde dann nächste Woche zum Testen bereit stehen.
Ansonsten hat die aktuelle Beta 1.5.7 das Auto Overlay Feature bereits. Die F1 Runs oben sind damit gemacht worden. Die Lastoptimierung würde dann nächste Woche zum Testen bereit stehen.
TE
TE
gaussmath
Guest
@PCGH_Dave @PCGH_Raff
Guten Morgen die Herren Redakteure,
das CX-Team war fleißig in den letzten Tagen (sonst natürlich auch ^^), so dass wir euch sehr wahrscheinlich heute Abend eine Testversion der v1.5.8 geben können. Ich muss noch ein klein wenig feinschleifen und testen, dann gibt's einen Link.
Beste Grüße, Mark
Guten Morgen die Herren Redakteure,
das CX-Team war fleißig in den letzten Tagen (sonst natürlich auch ^^), so dass wir euch sehr wahrscheinlich heute Abend eine Testversion der v1.5.8 geben können. Ich muss noch ein klein wenig feinschleifen und testen, dann gibt's einen Link.
Beste Grüße, Mark
TE
TE
gaussmath
Guest
Es geht auch darum, dass ihr die Version testet. Keiner kann so viele Testfälle abdecken wir ihr.
TE
TE
gaussmath
Guest
@Taxxor Man verlangt nach dir... ^^
TE
TE
gaussmath
Guest
@PCGH_Dave @PCGH_Raff
Download: v1.5.8 Beta
Keine Gewähr auf Vollständigkeit:
* CX ist jetzt eine 32 bit Anwendung, damit die Kommunikation mit dem RTSS reibungslos funktioniert. Der OSD Toggle welcher in CX getriggert wird, greift nun auch im RTSS. Insbesondere wird das OSD im RTSS global abgeschaltet, wenn die Auto-disable Funktion aktiv ist.
* Eine interne Sensorkonfiguration sorgt dafür, dass nur jene Sensoren ausgewertet werden, welche auch tatsächlich gebraucht werden.
* Man kann nun nach Begriffen in den Kommentaren suchen/filtern (Capture Liste). Klingt trivial, hatte ich aber tatsächlich vergessen.
* Komplett neuer Sensor Tab, siehe Anhang. Vollständig konfigurierbare Sensoren. Die Anzeigen beschränkt sich noch auf die bekannten Defaults, aber das machen wir noch. Alles was in der Liste angehakt wird, wird geloggt (jetzt schon!) und kann später angzeigt werden, auch grafisch.
* Die Hotkeys sind noch smarter geworden. Nafi und @Taxxor haben hier wirklich Raketenwissenschaft betrieben. Man kann nun beispielsweise Shift als Teil des Hotkeys verwenden und trotzdem den Run sprintend starten, was ja idR mit Shift gemacht wird.
Wichtiger Hinweis: Auch PresentMon wurde erneuert. Wir verwenden die Version 1.6.0. Das betrifft also auch den Capture-Kern von CX. Es ist natürlich unwahrscheinlich, dass PresentMon nun falsch arbeitet, aber wir haben die Messungen der Frametimes noch nicht gegen Build-in Benchmarks abgeglichen/validiert. Die Anbindung von PresentMon selbst haben wir nicht verändert.
Download: v1.5.8 Beta
Keine Gewähr auf Vollständigkeit:
* CX ist jetzt eine 32 bit Anwendung, damit die Kommunikation mit dem RTSS reibungslos funktioniert. Der OSD Toggle welcher in CX getriggert wird, greift nun auch im RTSS. Insbesondere wird das OSD im RTSS global abgeschaltet, wenn die Auto-disable Funktion aktiv ist.
* Eine interne Sensorkonfiguration sorgt dafür, dass nur jene Sensoren ausgewertet werden, welche auch tatsächlich gebraucht werden.
* Man kann nun nach Begriffen in den Kommentaren suchen/filtern (Capture Liste). Klingt trivial, hatte ich aber tatsächlich vergessen.
* Komplett neuer Sensor Tab, siehe Anhang. Vollständig konfigurierbare Sensoren. Die Anzeigen beschränkt sich noch auf die bekannten Defaults, aber das machen wir noch. Alles was in der Liste angehakt wird, wird geloggt (jetzt schon!) und kann später angzeigt werden, auch grafisch.
* Die Hotkeys sind noch smarter geworden. Nafi und @Taxxor haben hier wirklich Raketenwissenschaft betrieben. Man kann nun beispielsweise Shift als Teil des Hotkeys verwenden und trotzdem den Run sprintend starten, was ja idR mit Shift gemacht wird.
Wichtiger Hinweis: Auch PresentMon wurde erneuert. Wir verwenden die Version 1.6.0. Das betrifft also auch den Capture-Kern von CX. Es ist natürlich unwahrscheinlich, dass PresentMon nun falsch arbeitet, aber wir haben die Messungen der Frametimes noch nicht gegen Build-in Benchmarks abgeglichen/validiert. Die Anbindung von PresentMon selbst haben wir nicht verändert.
Zuletzt bearbeitet von einem Moderator:
TE
TE
gaussmath
Guest
@PCGH_Dave Den von dir reporteten Bug haben wir natürlich auch behoben.
KaterTom
Software-Overclocker(in)
Was mir jetzt erst auffällt: Ihr habt in der 1.5.8 beta bei den Sensoren das Powerlimit nicht mehr drin. Das finde ich seeehr schade!
Ich hatte in der Analysis Seite immer die Anzeige des Powerlimit Graphen aktiviert. Das war sehr hilfreich beim erstellen von voltage curves mit dem Afterburner!
Ich hatte in der Analysis Seite immer die Anzeige des Powerlimit Graphen aktiviert. Das war sehr hilfreich beim erstellen von voltage curves mit dem Afterburner!
T
-THOR-
Guest
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:
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.
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.
Zuletzt bearbeitet von einem Moderator:
TE
TE
gaussmath
Guest
Wir auch! Aber in der NvAPI hatte sich einiges geändert, so dass das PL dem zum Opfer gefallen ist, wir hoffen, dass wir das bald wieder integrieren können.
@-THOR- Als ich deine ersten Sätze las, dacht ich so, oh Gott, was ist jetzt los...
Wir verwenden PresentMon für die Auswertung der Frametimes. Wir nehmen den Datenstrom von PM so entgegen wie er kommt und ändern weder etwas daran, noch filtern wir die Daten.
PresentMon greift die Frametimes recht früh aus der Renderpipline ab, so dass man im Grunde von CPU-Frametimes sprechen kann. Das ist ein Grundvoraussetzung dafür, um auch CPUs (im CPU-Limit) mit CX testen zu können.
Was am Monitor angekommt, kann tatsächlich was ganz anderes sein. Da greifen noch unterschiedliche Buffer, die die eigentliche Bildaktualisierung (am Ende der Kette) beeinflussen können und auch tatsächlich tun.
Was du also als streuenden Graphen siehst, ist das, was deine CPU tatsächlich macht. Das geht wild hin und her, wird aber am Ende über Buffer "geglättet".
Zuletzt bearbeitet von einem Moderator:
T
-THOR-
Guest
Sorry für den Schock
.Aber lieber schreib ich zu viel, als zu wenig um mich im Nachhinein nicht trotzdem für alles erklären und rechtfertigen zu müssen. Danke fürs Lesen
Und auch Danke für die Erklärung.
Sowas ähnliches habe ich fast geahnt.
Dass hier Buffer am Werk sind, die die Ausgabe nochmal glätten. Ja absolut. Gibt ja auch das TripleBuffering bei Vsync, das alles glattbügeln sollte und dann eben auch dafür sorgt, dass die 16,6 ms in keinem Fall unterschritten werden.
Nur war bei mir eben grundsätzlich die Verwunderung, dass CapFrameX dieses Buffering bzw. eben einfach das was am Ende "rauskommt" überhaupt nicht aufzeichnet. Egal was ich eben machte, egal ob Vsync, FPS limiter, nix scheint die Frametimes bei CapFrameX glätten zu können. CapFrameX greift also wie du sagst viel früher im Rendering quasi auf CPU level. Das wusste ich nicht. Die Werte vom Afterburner scheinen eher dem zu entsprechen, was am Display ankommt. Zumindest sehe ich dort wie sich der Einsatz von Vsync und diversen FPS limitern auf die dort gezeigten Frametimes auswirkt.
Das würde auch erklären, warum sich tatsächlich die Frametimes in meinen getesteten Spielen zwischen CPU limit und GPU limit nicht sonderlich verbessert oder verschlechtert haben. Die Varianzen sahen ähnlich aus, obwohls im CPU limit spürbar etwas ruckeliger war.
Na gut, dann ist für mich soweit alles klar. Ich sehe den Sinn dahinter, es so zu machen, auch wenns nicht das ist, was ich vielleicht erwartet hätte.
Wäre denn für die Zukunft vielleicht ein zusätzlicher alternativer Ansatz denkbar? Sprich dass man zusätzlich an die Daten rankommt, die dem entsprechen, was am Ende am Display ankommt? Oder ist das für euch weniger interessant? Oder vielleicht gar nicht gut/einfach umsetzbar weil ihr eben nur die Daten von PresentMon verwendet.
Für mich persönlich wärs jetzt nicht wichtig. Aber für andere sicher interessant.
Zumindest finde ich, lassen die aktuellen Werte nen gewissen Interpretationsspielraum zu, der wohl auch zu Fehlinterpretation führen kann. (Was ja bei mir passiert ist).
Für den CPU Vergleich natürlich alles sehr interessant.
Aber du musst eben auch meine Ansicht verstehen. Ich messe da zig spiele, sehe nirgendwo dropped frames, alles ist perfekt und 100% smooth, obwohl mir CapFrameX die wildesten Frametime Varianzen zeigt. Hab schon fast an meinem Urteilsvermögen gezweifelt.
Aber ich labere schon wieder zu viel. Danke nochmal
TE
TE
gaussmath
Guest
Der Afterburner macht das tatsächlich anders mit der Argumentation, dass das eher dem entspricht, was der User vor dem Bildschirm wahrnimmt. Da es allerdings bei all den Benchmarks, um die Leistung der Kernkomponenten CPU und GPU geht, verwenden wir die PresentMon Daten, welche sozusagen "CPU-Frametimes" darstellen. Das wird in der Fachwelt genau so anerkannt. Die GPU Leistung kann man übrigens trotzdem/auch messen, weil die GPU im GPU-Limit entsprechende Wartezyklen verursacht, welche sich auf die Gesamtperformance auswirken.
Ähnliche Themen
- gaussmath
- Benchmarks
