• Hallo Gast, du kaufst gerne günstig ein und erfährst oft vor deinen Freunden von interessanten Angeboten? Dann kannst du dein Talent als Schnäppchenjäger jetzt zu Geld machen und anderen PCGH-Lesern beim Sparen helfen! Schau einfach mal rein - beim Test der Community Deals!

CapFrameX (CX) - Frametime Capture und Analyse Tool

Gouvi

Freizeitschrauber(in)
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.
 

PCGH_Dave

Redaktion
Teammitglied
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

  • Bug CX.PNG
    Bug CX.PNG
    122,3 KB · Aufrufe: 40

PCGH_Raff

Bitte nicht vöttern
Teammitglied
Moin!

Aha, eine neue Overlay-Option aka "temporäre Selbstzerstörung während des Benchens". Geil! Woher der Sinneswandel? Bisherige Messungen legen nahe, dass das unser künftiger Standard wird. :daumen:

[x] Neue Finalversion, pls =)

MfG
Raff
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
@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.

1610708586236.png
 

PCGH_Raff

Bitte nicht vöttern
Teammitglied
Geil! Auch, dass ihr die Kosten analysiert habt und senken konntet. Wann rechnet ihr mit einer präsentierbaren Version? Wir würden gerne in 1-2 Wochen neue Bench-Marathons starten, warten damit aber gerne auf die Version ... 1.6?

MfG
Raff
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
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.
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
@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
 

PCGH_Raff

Bitte nicht vöttern
Teammitglied
Moin Mark,

großartig, gute Arbeit. :daumen: Aber bitte stresst euch nicht unnötig. Wenn das Tool durch ein paar Tage mehr Zeit noch besser wird, dann nehmt sie euch bitte. Wobei ... mit einer Beta etwas fummeln können wir ja trotzdem. :D

MfG
Raff
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
Es geht auch darum, dass ihr die Version testet. Keiner kann so viele Testfälle abdecken wir ihr.
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
@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.

1611007963857.png
 
Zuletzt bearbeitet:

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!
 

-THOR-

Komplett-PC-Aufrüster(in)
Hallo zusammen,

textwall incoming. Aber was muss das muss :ugly:
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:
Screenshot 1.jpg


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:
Screenshot 2.jpg



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:
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
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!
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... :D

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:

-THOR-

Komplett-PC-Aufrüster(in)
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".

Sorry für den Schock :D.

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 :daumen:
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
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.
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
@PCGH_Raff @PCGH_Dave

Es hat sich doch noch einiges getan in den letzten Tagen. Neben jeder Menge Feinschliff, sind mehrere sehr interessante Memory Sensoren (System + GPU) hinzugekommen, außerdem wurde die Config überarbeitet, so dass Einstellungen nun nach einem Update nicht mehr verloren gehen.

Download

Update 28.01.2021
  • Bugfix to handle possible error while accessing config file on app startup
  • Changed "Used Memory Game" sensor to process performance counter "Working Set"
Important note: The "Used Memory Game" sensor is limited to 4GB because of 32 bit platform target

Der Status ist zwar noch offiziell Beta, aber es wurde sehr gut durchgetestet. Es ist also eher ein Release Candidate. Ich habe die Genauigkeit der Messungen zudem mit anderen bekannten Tools verglichen. Das passt alles soweit. Dabei fiel mir auf, wie komfortabel CX mittlerweile geworden ist. Automatische Ausreißererkennung, automatisches Aggregieren, Feedback auf dem Overlay, unmittelbarer Zugriff auf die Ergebnisse... das gibt's so kein zweites Mal. :-)

Change Log 1.5.8

## New features
  • Option to auto turn off overlay when capturing frametimes to reduce impact on the results.
  • Option to switch between turning off only CX overlay or global RTSS overlay via CX Hotkey.
  • New Sensor page to freely set the sensors that will be logged in benchmarks (Analysis page only shows the basic sensors, Sensor page shows all)
  • Custom resolution chart export for line graphs on Analysis, Comparison and Synchronization page via context menu (resolution can be set under global options)
  • Added "GPU FPS/10W" to metrics and changed "CPU FPS/W" to "CPU FPS/10W" (better visibility for bar charts)
  • Added "Used Memory Game", "GPU Memory Dedicated Game" and "GPU Memory Shared Game" to sensors to log the memory usage of the specific games.
  • Memory sensor for AMD cards provided by ADL ( equivalent to NvAPI)
## Enhancements
  • All sensors that are not used for logging or in the overlay won't be updated to further minimize performance impact
  • Improved hotkey handling (example: Hotkey "X" now also responds to modifier combinations like "Shift+X" as long as there is no other hotkey using that exact combination)
  • "Copy/paste" option for Record lists context menu
  • User config is now saved as JSON in the Documents folder to be persistent when installing new versions.
  • General performance optimizations
## Bug fixes
  • Possible Hotkey sound delay
  • Legends on Comparison page may still be visible even if toggled off
  • Missing power and VRAM (dedicated memory) sensor for AMD GPUs
 
Zuletzt bearbeitet:

PCGH_Raff

Bitte nicht vöttern
Teammitglied
Sehr geil, weiter so. :daumen:

Ich habe die erste große (RX-6900-)Messreihe mit der vorherigen 8er-Beta hinter mir. Alles super soweit. Hotkey-Sound geht wieder (weicht aber nun dem Overlay mit Auto-Off) und die Sensoren funktionieren. Allerdings hatte ich einige Abstürze des Tools, als das observierte Verzeichnis ziemlich mit Messungen "zugemüllt" war.

So, RTX 3080 startet.

Beste Grüße,
Raff
 

Taxxor

PC-Selbstbauer(in)
Allerdings hatte ich einige Abstürze des Tools, als das observierte Verzeichnis ziemlich mit Messungen "zugemüllt" war.
In solchen Momenten wäre es natürlich gut gewesen, den crashlog hochzuladen oder den Log Eintrag hier zu melden, damit wir auch an einer Lösung arbeiten können.
Ich gehe mal nicht davon aus, dass du noch exakt weißt, wann ein solcher Absturz zuletzt passiert ist und es in deinen Log Files raussuchen kannst?

Und um wieviele Messungen handelt es sich denn in etwa?
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
Bitte jeden Fehler nach Möglichkeit melden, auch wenn es noch so unscheinbar oder selten ist. Danke euch!
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
@PCGH_Raff @PCGH_Dave

Hab mal ein Update eingefügt. Wirklich kriegsentscheidend ist das aber nicht. Es sei denn, ihr habt bereits einen Artikel auf Basis des neuen "Used Memory Game" Sensors gemacht... :D
 
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
Ein weiteres kleines Update. Der "Used Memory Game" Sensor ist limitiert auf 4GB, da CX derzeit in 32 bit kompiliert ist. Wir arbeiten an einer Lösung.
 

HisN

Kokü-Junkie (m/w)
Auch Unwinder klammert sich an die 32Bit-Kompatibilität. Was hat es damit auf sich, wenn ich fragen darf?
 

Taxxor

PC-Selbstbauer(in)
@HisN Das wüsste ich auch gerne^^
Dass CX in der zuletzt verlinkten Version 32bit war, liegt nämlich genau daran, dass der RTSS auch 32bit läuft und wir die Steuerung des globalen Overlay toggles nur vernünftig hinbekommen, wenn wir sie aus einer 32bit Anwendung aus aufrufen.

Sprechen wir als 32bit Version die normale RTSSHooks.dll an, dann verwaltet der RTSS das ganze intern auf 32 und 64bit Anwendungen und setzt den Toggle auf der Oberfläche entsprechend.

Es gibt aber auch die RTSSHooks64.dll und die können wir auch über 64bit ansprechen, allerdings reagiert dann die UI von RTSS nicht auf den veränderten Status und das Overlay lässt sich damit auch nur in Spielen komplett ausschalten, die ebenfalls 64bit sind.

Diese Einschränkungen haben wir jetzt erst mal so hingenommen und sind mittlerweile wieder bei 64bit.
Dadurch musste die Option rausfliegen, dass man den globalen RTSS Toggle mit unserem Hotkey steuern kann.

Das würde zwar prinzipiell immer noch funktionieren (99% der heutigen Games sind ja 64bit) aber es ist einfach blöd, wenn der Toggle im RTSS dann weiterhin auf ON steht, obwohl es eigentlich abgeschaltet ist. Das kann zu verwirrung führen, wenn man das Overlay mal mit CX abgeschaltet hat und sich später, wenn man z.b. nur HWInfo anzeigen lassen will, fragt warum kein Overlay zu sehen ist, obwohl der RTSS sagt, dass es an ist. Zugegeben seltene Fälle, aber es stört mich einfach^^


In unseren letzten Performance Messungen hat sich gezeigt, dass zwischen CX Overlay an und aus nicht wirklich ein Unterschied besteht(max 1%, im Schnitt eher 0,5% in meinen Tests mit relativ schlankem Overlay), solange das globale RTSS OSD weiterhin an bleibt.
Schaltet man dieses zusätzlich ab, können da schon noch mal 2-3% bei rum kommen, auch wenn es im aktivierten Zustand nichts angezeigt hat. Ein komplett geschlossener RTSS bringt dann auch keine Mehrperformance mehr.

Hier eine der Auswertungen.
"Auto" ist das auto-disable des Overlays während der Aufnahme, hier im Test noch ohne globale Steuerung des RTSS, "Off + RTSS Off" ist mit komplet geschlossenem RTSS und "Auto+RTSS Toggle off" ist das was wir jetzt aktuell haben.
Screenshot 2021-01-30 224644.png


Die Option, es zu deaktivieren während eine Aufnahme läuft, ist somit drin geblieben, da es hier ja am Ende sowieso wieder eingeschaltet wird und der Toggle somit optisch wieder passt.
Wenn man nun ein 32bit Spiel bencht, wird halt nur das CX Overlay deaktiviert, der RTSS bleibt aber an.

Damit müssen wir vorerst leben und vielleicht haben wir irgendwann in Zukunft auch mal einen 32bit Service der nebenher läuft und unsere Befehle an den RTSS überträgt. Die ersten Versuche in der Richtung liefen nicht so wirklich, sodass es leichter war, einfach komplett in 32bit zu arbeiten. Der Wegfall der PCIe Bandbreitensensoren(die nur in 64bit angesprochen werden können) war noch verschmerzbar, aber die Geschichte mit dem RAM war dann zu viel.
 
Zuletzt bearbeitet:

HisN

Kokü-Junkie (m/w)
Danke für die Erklärung. Ich freue mich sehr, wenn ihr uns mit den Hintergründen füttert.


Ich hatte Unwinder mal darauf im Guru3D angesprochen ... natürlich aus einem anderen Grund, aber hier wäre seine Antwort.

 

Taxxor

PC-Selbstbauer(in)
Die Option zum automatischen deaktivieren während der Aufnahme ist generell ja eigentlich auch nur für Reviewer interessant, die unterschiedliche Hardware vergleichen und sicherstellen wollen, dass das Overlay z.b. eine schwächere CPU nicht um 4% einbremst und eine stärkere nur um 1%.
Für den normalen Nutzer hat es nicht viel Relevanz, da man ohne Overlay dann evtl 2-3% mehr Performance in der Messung hat, aber das Overlay sowieso meist nebenher an hat und somit eigentlich nicht das misst, was für einen selbst Realität ist.
Schön, wenn ich 102FPS messe, aber spielen tu ich dann mit Overlay und 100FPS
 

Olstyle

Moderator
Teammitglied
Charmant wie immer^^ Darum müssen wir uns nicht kümmern, da PresentMon bei uns sowieso nur mit Windows 7 aufwärts funktioniert und seinerseits 64bit ist. Von daher könnte ein altes 32bit System CX sowieso nicht richtig nutzen.
In Russland gehen die Uhren was OS-Nutzung an geht auch etwas anders, das sollte man als Besserwessi nicht unterschätzen ;) .
 

Taxxor

PC-Selbstbauer(in)
@PCGH_Dave
Wann rechnet ihr mit einer präsentierbaren Version? Wir würden gerne in 1-2 Wochen neue Bench-Marathons starten
So, exakt 2 Wochen und 2 Tage nach diesem Post ist die 1.5.8 jetzt final und ihr bekommt den ersten Link dazu, noch bevor sie heute im Laufe des Tages irgendwann auf die Webseite kommt^^


Die einzige größere Änderung im Vergleich zu der Version die ihr momentan habt, ist, dass wir wieder auf 64bit sind und somit der "Used Memory Game" Sensor wieder Werte über 4GB anzeigen kann, dieser ist jetzt auch als Standard RAM Sensor gewählt und wird anstelle der Gesamtnutzung auf der Analysis angezeigt.
Für Aufnahmen mit älteren Versionen, die noch die Gesamtnutzung geloggt haben, wird der RAM nicht mehr an dieser Stelle gezeigt, kann aber nach wie vor auf der Sensor Page gesehen werden.


Kompletter Changelog
## New features
  • Option to auto turn off overlay when capturing frametimes to reduce impact on the results.
  • New Sensor page to freely set the sensors that will be logged in benchmarks (Analysis page only shows the basic sensors, Sensor page shows all)
  • Custom resolution chart export for line graphs on Analysis, Comparison and Synchronization page via context menu (resolution can be set under global options)
  • Added "GPU FPS/10W" to metrics and changed "CPU FPS/W" to "CPU FPS/10W" (better visibility for bar charts)
  • Added "Used Memory Game", "GPU Memory Dedicated Game" and "GPU Memory Shared Game" to sensors to log the memory usage of the specific games.
  • Experimental support for Intel Rocket Lake CPUs


## Enhancements
  • Sensors that are neither used while logging nor displayed in the overlay won't be updated to further minimize performance impact
  • Improved hotkey handling (example: Hotkey "X" now also responds to modifier combinations like "Shift+X" as long as there is no other hotkey using that exact combination)
  • "Copy/paste" option for Record lists context menu
  • User config is now saved as JSON in the Documents folder to be persistent when installing new versions.
  • Record list search bar now also works with comment lines.
  • General performance optimization


## Bug fixes
  • Possible Hotkey sound delay
  • Legends on Comparison page may still be visible even if toggled off
  • Missing power and VRAM sensor for AMD GPUs
 
Zuletzt bearbeitet:
TE
gaussmath

gaussmath

Lötkolbengott/-göttin
Wir haben das mit dem Plattformwechsel gründlich abgewägt. Nachdem wir festgestellt hatten, dass das Auto disable mit der 64 bit Hook DLL vom RTSS auch wie gewünscht funktioniert, haben wir entschieden zurück auf 64 bit zu gehen.

Ich war ehrlich gesagt ein wenig angefressen, dass die PCIe Durchsatzsensoren rausfliegen mussten, auch wenn @Taxxor meint, das sei verschmerzbar. ^^ Diese Sensoren kommen aus der NVML DLL und die gibt's leider nicht als 32 bit Version.

Als dann die Sache mit den neuen RAM Sensoren auch nicht klappte, hatten wir die Schnauze endgültig voll.
 
Oben Unten