CapFrameX - Capture und Analyse Tool

[Shir Khan]

Hi,

ich bekomme 3DMark Time Spy nicht gecaptured. Setze ich den Prozess auf die Ignore List, passiert das was im Protokoll rechts oberhalb des Doppelstrichs steht. Lass ich den Prozess drin, passiert das was unterhalb des Doppelstrichs steht.



Alle CFX-Einstellungen sind default. Was mache ich falsch?

Edit: Ok, hab's gefunden. Der Prozess muss nicht auf die ignore list, aber das Capturing muss vor Time Spy gestartet werden. Dann geht's. Aber dadurch wird natürlich der komplette System-Scan und der Benchmark-Ladescreen mitaufgezeichnet, wass ich eigentlich vermeiden wollte.

 

[Taxxor]

Aber dadurch wird natürlich der komplette System-Scan und der Benchmark-Ladescreen mitaufgezeichnet, wass ich eigentlich vermeiden wollte.

Das kannst du ja alles nachträglich rausschneiden.

3D Mark ist in der Tat blöd zu benchen weil die frametimes alle über die Haupt exe laufen und nicht über die einzelnen Prozesse die für die Tests gestartet werden.
Man denkt natürlich erst mal, dass man die timespy exe braucht und setzt 3DMark auf ignore, aber dann kommen halt keine Daten an.

Was du aber machen kannst ist genau das Gegenteil, also timespy auf ignore setzen, oder alternativ 3DMark in der Liste anklicken damit immer dieser Prozess aufgenommen wird.
In beiden Fällen ist es dann egal, wenn später der timespy Prozess startet, die Aufnahme läuft immer für den 3DMark Prozess

(Einer der wenigen Fälle wo man die Funktion, Prozesse manuell auszuwählen, wirklich mal gebrauchen kann^^)

 

[Taxxor]

Version 1.6.6 ist fertig
https://www.capframex.com/news/detail/New version 1.6.6

Spoiler: Changelog

## New features

• Support for Intel Alder Lake CPUs (sensor info and detection of performance and efficiency cores)
• Move record files into different tree view folders via drag & drop(needs tree view to be pinned)
• Status of ResBar, GameMode and HAGS are saved in record files and included in system info expander
• Notifications inside CX for us to send important messages to all users on app start when neccessary
• Overlay values accessible through http and web socket (links provided in options menu)
• "System time" as new overlay entry to simply show the current time
• Max core temperature added to sensors (Intel)

## Enhancements

• Autostart using scheduled task to remove UAC prompt
• Record list search bar now also shows the number of records in the current directory
• Run history and aggregation options moved from Overlay to Capture page as they are more connected to the capturing process
• Further compressed overlay entry formats to display more entries without glitches
• Custom capture time for a process can now be saved directly with a save button instead of having to do a capture for it
• Group control on overlay page includes CPU core voltages
• Variances and input lag calculated separately for each run of an aggregated session, then added together to exclude the differences between the last frame of a run and the first frame of the next run
• Input lag calculation changed to include the possible impact of dropped frames and input sampled post-present in the upper bound and for input sampled pre-present in the lower bound.

## Bug fixes

• Possible fixes for crashes regarding sound manager and overlay entries
• OS version wasn't showing in system info expander

 

[AthlonXP]

Download

findet man keine vorabversionen mehr unter dieser adresse, jetzt nur noch die offiziellen beta versionen auf github ?

 

[Taxxor]

findet man keine vorabversionen mehr unter dieser adresse, jetzt nur noch die offiziellen beta versionen auf github ?

alle neusten builds sind unter archive.capframex.com zu finden

 

[AthlonXP]

danke

 

[ZeroStrat]

danke

Wobei das unser Build Archiv ist. Wenn wir ein Beta auf GitHub veröffentlichen, dann steckt da auch ein gwisser Testaufwand dahinter, so dass man mit einer relativ stabilen Version rechnen kann. Ins Build Archiv kommt alles rein. Ich für meinen Teil pushe da auch mal Halbgares Zeug rein (verrate es aber nicht den anderen ), also keine "Garantie" für Stabilität. Zur Not einfach ausprobieren oder nachfragen hier im Thread.

 

[Wolfgang]

Nach langer Feedback-Pause habe ich zwei Anmerkungen.
Das Tool an sich ist übrigens nach wie vor Klasse, gibt nichts, was auch nur im Ansatz daran kommt

- Wisst ihr von einem Bug, durch den CX 1.6.6 nach einigen Benchmarks plötzlich gar nicht mehr reagiert auf weitere Capture-Befehle? Das ist mir jetzt schon mehrmals aufgefallen. Ich erstelle verschiedene Benchmarks in verschiedenen Spielen und ohne ersichtlichen Grund reagiert dann CX irgendwann nicht mehr auf weitere Capture-Befehle. Auch das Spiel neu starten oder ein anderes Spiel starten ändert daran nichts. Es hilft dann nur noch, das Tool zu schließen und wieder zu öffnen, dann gehts wieder normal.

Leider kann ich für das Verhalten keinen Grund erkennen und genauso wenig ein System. Es passiert relativ selten, daher ist das kein wirkliches Problem und wohlmöglich auch noch gar keinem oder nur wenigen anderen aufgefallen. Aber das ganze passiert schon immer mal wieder, mit CX1.6.6. ist das jetzt sicher 4, 5 Mal passiert.

- Derzeit erstelle ich wieder komplett neue Grafikkarten-Benchmarks und da fällt es echt auf, dass moderne Hardware + moderne Spiele immer mal wieder echt schlecht reproduzierbare Frametimes und damit auch Perzentil-FPS haben. Durch X-Läufe kann man das zwar etwas ausgleichen, optimal ist das aber bei weitem nicht.

Aus dem Grund habt ihr ja auch das 0,2% Perzentil eingeführt, ich nutze mittlerweile aber oft nur noch das 1% Perzentil. Das ärgert mich schon ein wenig, da dies halt schon recht viele schlechte Frames durchgehen lässt, aber das 0,2% ist in vielen Spielen echt leider nicht mehr praktikabel. Daher meinen Vorschlag für eine Zwischenlösung: Was haltet ihr von einem 0,5% Perzentil als Kompromiss? Ja, dann gibt es da zwar schon eine Menge Möglichkeiten mit dem 0,1, 0,2 etc., aber das wäre denke ich deutlich praktikabler und durchgängiger nutzbar als 0,2% etc., zugleich aber deutlich strenger als das 1%.

 

[Taxxor]

Aus dem Grund habt ihr ja auch das 0,2% Perzentil eingeführt, ich nutze mittlerweile aber oft nur noch das 1% Perzentil.

Eigentlich andersrum, wir hatten nur 0.1% und 1% und haben dann 0.2% dazu genommen, weil ihr das genommen habt^^

Das aber auch nur zur Auswertung, für die aggregation würde ich das nie verwenden, da ist mir in vielen Games schon P1 oft zu sprunghaft und ich gehe von 3 auf 5% hoch um nicht alles 10mal machen zu müssen^^

Ich persönlich würde dir auch mal die 1% low als Ausreißererkennung empfehlen, die ja bei uns nicht der avg der schlechtesten 1% sind, sondern so funktionieren, dass die schlechtesten Frametimes addiert werden, bis 1% der Aufnahmezeit erreicht ist(250ms bei 25s Aufnahme), der Frame der an der Stelle steht, ist dann der Wert für 1% low.

Der ist idR immer etwas geringer als das P1(aber nicht viel) und dadurch, dass einzelne größere Ausreißer den Wert direkt stark verschieben können(da er Zeitbasiert und nicht Framezahlbasiert ist), auch strenger als P1, aber ich hab ihn noch nie niedriger als P0.2 gesehen.


Generell kannst du dir durch die Prozente aber ja jede metrik mehr oder weniger streng gestalten, wenn P0.2 mit 3% zu streng und P1 mit 3% zu lasch ist, dann nehm halt P1 mit 2% oder P0.2 mit 5%

Ergänzung (24. November 2021)

- Wisst ihr von einem Bug, durch den CX 1.6.6 nach einigen Benchmarks plötzlich gar nicht mehr reagiert auf weitere Capture-Befehle?

Nein, seit der 1.5.irgendwas, wo der Fehler mal reproduzierbar drin war, nie wieder untergekommen das Verhalten.
@ZeroStrat hat auch die letzten Wochen unzählbar viele Benchmarks gemacht und es lief immer durch.

Du hast ja den Capture Log an der Seite, da müsste immer was auftauchen, auch wenn die Aufnahme nicht gestartet werden konnte, solange der Hotkey bis zum Capture Service durchgekommen ist. Wenn da nach dem Hotkey gar nix auftaucht, wäre das schon mal ein Anhaltspunkt.

 

[ZeroStrat]

Wisst ihr von einem Bug, durch den CX 1.6.6 nach einigen Benchmarks plötzlich gar nicht mehr reagiert auf weitere Capture-Befehle? Das ist mir jetzt schon mehrmals aufgefallen. Ich erstelle verschiedene Benchmarks in verschiedenen Spielen und ohne ersichtlichen Grund reagiert dann CX irgendwann nicht mehr auf weitere Capture-Befehle. Auch das Spiel neu starten oder ein anderes Spiel starten ändert daran nichts. Es hilft dann nur noch, das Tool zu schließen und wieder zu öffnen, dann gehts wieder normal.

Ich habe mit CX in den letzten Wochen hunderte Runs aufgezeichnet auf völlig unterschiedlichen Systemen. Es gab nicht ein einziges Problem. Erstaunlich eigentlich, wie zuverlässig die Software mittlerweile geworden ist.

Wenn du Probleme mit dem Capture Hotkey hast, vermute ich eine externe Ursache dahinter. Welchen Hotkey verwendest du? Ich nutze im Grunde nur noch den "><|" Key zwischen Shift und Y. F-Keys werden gerne mal extern "verschluckt".

Ein Logging File wäre hilfreich für uns, um die Ursache besser eingrenzen zu können.

Aus dem Grund habt ihr ja auch das 0,2% Perzentil eingeführt, ich nutze mittlerweile aber oft nur noch das 1% Perzentil. Das ärgert mich schon ein wenig, da dies halt schon recht viele schlechte Frames durchgehen lässt, aber das 0,2% ist in vielen Spielen echt leider nicht mehr praktikabel. Daher meinen Vorschlag für eine Zwischenlösung: Was haltet ihr von einem 0,5% Perzentil als Kompromiss? Ja, dann gibt es da zwar schon eine Menge Möglichkeiten mit dem 0,1, 0,2 etc., aber das wäre denke ich deutlich praktikabler und durchgängiger nutzbar als 0,2% etc., zugleich aber deutlich strenger als das 1%.

Wie @Taxxor schon sagte, das 0,2% Perzentil haben wir wegen euch drin. Ich selbst nutze nur noch das 1% Perzentil für meine Auswertungen. Es "unterschlägt" zwar Spikes in den Frametimes, aber das macht es zu einem starken Partner im Alltag. Schlechte Frametimes/Spikes in einer Metrik abbilden zu wollen, ist ein Kampf gegen Windmühlen. Am Ende sind es immer die stochastischen, nicht reproduzierbaren Ausreißer, die dir die Suppe versalzen. Es gibt natürlich auch reproduzierbare Spikes, aber die musst du erstmal als solche identifizieren.

Aus mathematischer Sicht bin ich strikt gegen Metriken, welche nicht in der Lage sind, Ausreißer geschickt zu behandeln. Daher rate ich auch entgegen des Vorschlags von @Taxxor dringend dazu, die Finger von den Low Integral Metriken zu lassen. Dazu muss man sich nur Charts von Gamers Nexus anschauen. Mir rollen sich jedes Mal die Fußnägel hoch, wenn ich das sehe. Integral Metriken sind Gegner der Konsistenz.

Ich würde andere Mittel hinzuziehen, um Spikes zu zeigen, beispielsweise einfach Frametimegraphen, aber am Ende hast du immer das Problem, dass du potentiell (nur) stochastische Ausreißer zeigst. Streng genommen, haben nur reproduzierbare Ausreißer was zu suchen in einer Performanceanalyse.

 

[Taxxor]

@Taxxor dringend dazu, die Finger von den Low Integral Metriken zu lassen. Dazu muss man sich nur Charts von Gamers Nexus anschauen. Mir rollen sich jedes Mal die Fußnägel hoch, wenn ich das sehe. Integral Metriken sind der Gegner der Konsistenz.

Gamersnexus Werte haben aber auch nichts mit unseren Low Integrals zu tun…

Wie gesagt, ich kann unsere 1% low mit 3% Toleranz genau so gut mit der Aggregation nutzen wie P1 von der Konsistenz her.

Mit dem Vorteil dass es wie eine Mischung aus P1 und P0.2 arbeitet, indem auch ein paar wenige Ausreißer schon als invalider run gewertet werden könnten, wenn sie groß genug sind, also genau das was man eigentlich möchte.
Kleine Ausreißer würden so nicht reinkommen, während das P0.2 sie drin hätte.
Die kämen nur rein wenn sie auch signifikant sin

Sprich wenn ein Spiel reproduzierbar für 300ms hängt an einer Stelle, würden weder P1 noch P0.1 das auffangen weil es ja nur ein einziger Frame ist, der bei beiden ignoriert werden würde.
So ein 300ms Ruckler würde vom 1% Low aber aufgenommen werden, da bereits mit diesem einen Frame 1% der Aufnahmezeit erreicht/überschritten wurde

 

[ZeroStrat]

Gamersnexus Werte haben aber auch nichts mit unseren Low Integrals zu tun…

Indirekt halt schon. Auch wenn GN einen Low Average Ansatz verwendet, die Gemeinsamkeit ist, dass Ausreißer mit einfließen in die Berechnung, was man an den Charts von GN mehr als deutlich sieht. Unser Low Integral Ansatz ist ähnlich empfindlich gegen Ausreißer. Das ist bah!

Mit dem Vorteil dass es wie eine Mischung aus P1 und P0.2 arbeitet, indem auch ein paar wenige Ausreißer schon als invalider run gewertet werden könnten, wenn sie groß genug sind, also genau das was man eigentlich möchte.
Kleine Ausreißer würden so nicht reinkommen, während das P0.2 sie drin hätte.
Die kämen nur rein wenn sie auch signifikant sin

Sprich wenn ein Spiel reproduzierbar für 300ms hängt an einer Stelle, würden weder P1 noch P0.1 das auffangen weil es ja nur ein einziger Frame ist, der bei beiden ignoriert werden würde.
So ein 300ms Ruckler würde vom 1% Low aber aufgenommen werden, da bereits mit diesem einen Frame 1% der Aufnahmezeit erreicht/überschritten wurde

Das ändert nichts an dem fundamentalen Problem, dass man als Tester nicht immer zuverlässig weiß, ob die Ausreißer stochastisch oder systematisch sind. Was nützt es einem, wenn die Integral Metrik hierbei dämpfend wirkt und dann (die im Grunde ungwollten) Ausreißer "ja nicht so schlimm sind"?

Für mich geht's halt auch um Alltagstauglichkeit und Konsistenz. Im Zweifel sollte man die Ausreißer besser rausfiltern, gerade wenn es um die Leistungsankings geht. Man muss es ja nicht komplett ignorieren, @Wolfgang kann immerhin noch die (ungefilterten) Frametimegraphen zeigen.

 

[Wolfgang]

Als Aufnahme-Key benutze ich ganz klassisch "F12", das funktioniert eigentlich immer einwandfrei (und hat es mit älteren CX-Versionen auch immer). Ich kann das Verhalten gerne mal im Auge behalten und wenns wieder auftaucht, mal einen Blick auf den Log werfen, vielleicht sagt der ja was. Wenn nichts sinnvolles bei rum kommt, kann ichs auch mal mit einer anderen Tastenbelegung versuche, ich habe aber zumindest meine Zweifel, dass das wirklich an F12 liegt. Aber ja, wer weiß das schon wirklich

Schlechte Frametimes/Spikes in einer Metrik abbilden zu wollen, ist ein Kampf gegen Windmühlen.

Ja, das ist es definitiv, wirklich happy ist man nie darüber. Da werde ich mir nochmal ein paar Gedanken drüber machen. Und danke für euer Feedback!

Ergänzung (25. November 2021)

Manchmal ist das Glück dann doch auf seiner Seite, ich hatte das Problem gerade wieder.
Und im Log steht tatsächlich was, vielleicht hilft das ja in irgendeiner Form

Das Spiel war auch nur Zufall, hatte den Fehler auch schon in anderen Titeln als Far Cry 6.

 

[ZeroStrat]

Manchmal ist das Glück dann doch auf seiner Seite, ich hatte das Problem gerade wieder.
Und im Log steht tatsächlich was, vielleicht hilft das ja in irgendeiner Form

Das Spiel war auch nur Zufall, hatte den Fehler auch schon in anderen Titeln als Far Cry 6.

PresentMon meldet keine Infos zurück an CX. Es wird kein Prozess erkannt. Den Fehler hatte ich schon sehr lange nicht mehr gehabt. Verwendest du auch andere Capture Software neben CX?

 

[Wolfgang]

Nein, nebenbei läuft keine andere Capture-Software, einzig der Afterburner, aber das ist ja eine anderen Art von "Capture".

 

[ZeroStrat]

Nein, nebenbei läuft keine andere Capture-Software, einzig der Afterburner, aber das ist ja eine anderen Art von "Capture".

Meinst du den Afterburner oder RTSS?

 

[Wolfgang]

Nur den Afterburner, RTSS ist aus (sowohl bei CX als auch beim AB).

 

[ZeroStrat]

Ich würde jetzt mal als Maßnahmen vorschlagen:

• Keine andere Software nebenher, die auf Sensoren ode ETW Events zugreifen könnte: HWiNFO, Afterburner, EVGA Precision X1
• Keine Windows Tweaks verwenden (machst du ja vermutlich eh nicht)
• Grafiktreiber mit DDU sauber neuinstallieren
• Virtualisierung abschalten, wenigstens mal testweise. Ich hatte das immer aus gehabt bei meinen Tests.

 

[Wolfgang]

1. Mehr als den AB habe ich nicht, der im Hintergrund rumeiert. Den kann ich mal abschalten und schauen.
2. Mache ich eh nicht. Ist quasi nen Stock Win 11 mit ner Handvoll geänderter Einstellungen in der Systemsteuerung, wobei es da aber primär um Netzwerk oder sowas geht.
3. Kann ich mal machen.
4. Testweise kann ich das mal machen. Aber dann muss der Fehler zufällig schnell zu reproduzieren sein, weil ich sonst ja stundenlang für die Katz rumbenchen würde.

 

[Taxxor]

Das ändert nichts an dem fundamentalen Problem, dass man als Tester nicht immer zuverlässig weiß, ob die Ausreißer stochastisch oder systematisch sind.

Das weiß ich ja bei den Perzentilen auch erst, wenn ich mehrere Runs gemacht habe.
Wenn ich 4 Runs mache und in 2 ist das P1 niedriger als in den anderen 2, habe ich dann in 2 Runs ein paar Außreißer zuviel drin als gewöhnlich oder habe ich in den anderen 2 Runs ein paar Außreißer zu wenig?


Genau so sehe ich auch erst nach mehreren runs, ob der in meinem beispiel genannte 300ms Ruckler (oder lass es 3-4 75ms Ruckler sein) immer wieder auftritt, was dann er Fall ist, wenn meine 3 Runs in den 1% low konsistent sind.

Was nützt es einem, wenn die Integral Metrik hierbei dämpfend wirkt und dann (die im Grunde ungwollten) Ausreißer "ja nicht so schlimm sind"?

Wenn die Ausreißer, die unterhalb des P1 vorgekommen sind, in ihrer Stärke deutlich weniger ausgeprägt waren als bei einer anderen GPU, die zwar die gleiche Menge an Ausreißern hatte, diese aber allesamt höher ausgefallen sind, dann ist das doch ein Unterschied, den man wissen wollen würde.

(Ja im Fall von CX kann man das mit dem Stuttering und Variance Chart näher analysieren, aber so aus dem Spiel raus mit der Run History bildet 1% Low im Grunde eine Mischung aus diesen ganzen Tools in einer Zahl an)

Wenn eine GPU 30% bessere 1% lows hat, obwohl man mit P1 vllt nur auf 20% Unterschied kommen würde, dann ist die Sache ja nicht inkonsistent, man darf ja davon ausgehen, dass für jede GPU trotzdem mehrere Runs gemacht wurden, die auch untereinander validiert wurden.
Und da hat dann GPU B eben unterhalb des P1 reproduzierbar stärkere Ausreißer gehabt als GPU A und das sieht man da dann halt sofort.

Ergänzung (25. November 2021)

Und im Log steht tatsächlich was, vielleicht hilft das ja in irgendeiner Form

Man sieht ja auch, dass das Game nicht in der Liste ist, PresentMon hat es also "verloren"

In dem Fall müsste aber eigentlich auch der "Rescan" Button über der Prozessliste helfen, damit startest du PresentMon neu(was auch passiert wenn du CX neustartest)