Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
CapFrameX (CX) - Frametime Capture und Analyse Tool
Stell in den Optionen doch einfach ein, dass du eine Aggregation haben willst.
Sollte ein Ergebnis stark abweichen (je nach Einstellung wie hoch die Abweichung sein darf -> Dave misst mit 5%) wird dir auch angezeigt, das eine Aufnahme abweicht und du kannst es erneut machen.
Ich schalte mich mal noch ein, da du von Mittelwerten sprichst: Die hier von @Darkearth27 gezeigte Aggregation bildet nicht den Mittelwert, sondern nimmt wirklich alle Rohdaten zusammen als einen Datensatz.
Der einzige Wert, der danach wirklich der Mittelwert aus den drei Durchläufen ist, sind die avg FPS(liegt in der Natur der Metrik^^)
Hast du z.B. ganz theoretisch in den 3 Durchgängen ein P1 von 10, 40 und 45 FPS, dann wird dein P1 in der aggregierten Datei nicht 31,66 FPS betragen, sondern er wird aus den ganzen Rohdaten nochmal neu berechnet.
Somit könnte dieser dann immer noch nur bei 10-15 FPS liegen, wenn eben aus der nun dreifachen Menge an Frametimes weiterhin 1% niedriger als das ist.
Noch simpler ist es mit den absoluten min FPS erklärt: hast du hier 5, 10 und 15 wäre der Mittelwert 10, aber bei der Aggregation dieser 3 Benches wird der min FPS Wert des neuen Datensatzes 5 sein.
Auf der Sensor Page hast du auch die Möglichkeit, die Werte von mehreren Einträgen entweder aggregiert oder gemittelt anzuzeigen, da kann man den Unterschied auch gut sehen, weil es hier min und Max Werte gibt und es schon was ausmacht, ob ich 3 Min Werte miteinander mittle oder ob ich wirklich den niedrigsten Min Wert als neuen Min Wert nehme.
Willst du einen wirklichen Mittelwert sehen, geht das über die Report Page, da hast du eine extra Spalte für die Mittelwerte.
Die Aggregation simuliert einfach nur, dass du diese 3 Runs direkt hintereinander gemacht hast und wertet sie auch wie 3 Runs, nur eben innerhalb einer einzigen Aufnahme.
Mit der automatischen Aggregation und Ausreißererkennung kann man so schon beim Benchen sicher gehen, dass die Runs stabil sind und nicht zu sehr voneinander abweichen.
Man kann aber auch bewusst Runs miteinander verbinden, die voneinander abweichen, wenn man beim Outlier Handling "Mark & Use" einstellt(oder es eben auf der Aggregation Page nachträglich so macht).
Ich nutze das z.B. um Benchmarks zu erstellen, die unterschiedeliche Szenen abbilden, man kann z.B. im Tomb Raider integrierten Bench jede der 3 Szenen einzeln Benchen und durch das aggregieren erhält man eine Datei, die simuliert als wären die 3 Szenen direkt aneinander gelaufen ohne Ladesequenzen dazwischen.
Das lässt sich auch auf custom Benchmarks anwenden, wenn man sich die Mühe machen will und eine praxisnähere Performanceangabe bieten möchte, als einfach ein Worst Case Szenario zu testen.
So könnte man z.B. sagen:
Wir testen Spiel X und in Spiel X ist man zu ~50% der Zeit in Außenarealen einer Open World wo man ~80FPS hat, zu ~25% der Zeit in Innenräumen der Open World wo man ~100FPS hat und zu ~25% der Zeit in instanzierten Dungeons mit großen Kämpfen, wo man ~60FPS hat.
Dann macht man einfach 3 Benchmarks, einen in der Open World, einen in Innenräumen und einen in einem Dungeon.
Beim Aggregieren packt man nun die 3 zusammen und nimmt zusätzlich noch den der Open World nochmal dazu, sodass man insgesamt 4 Benches drin hat und der der Open World doppelt so viel zählt wie die anderen, weil dies auch im Spiel am häufigsten zu sehen ist.
Dann bekommt man einen Avg FPS Wert, der ziemlich gut den Mittelwert des Spiels abbildet(in dem Fall ~80), aber gleichzeitig bekommt man auch einen P1 oder P0.1 Wert, der näher am "Worst Case" ist, da dieser mit ziemlicher Sicherheit fast ausschließlich durch dem Bench mit den niedrigsten FPS bestimmt wird.
Wenn ich deinen Satz so lese, hört es sich für mich so an, als denkst du, dass damit vor dem aggregieren ausreißende Frametimes innerhalb der einzelnen Runs rausgefiltert werden würden, wie es auf der Analysis Page mit dem "Remove Outliers" Toggle gemacht wird. Falls ja, das ist nicht so^^
Outliers sind einfach nur diejenigen Runs, die in der Tabelle wie auch im Overlay entsprechend Rot markiert sind, weil sie in der gewählten Metrik zu sehr von den anderen Runs abweichen.
"Including outliers" nutzt alle runs in der Tabelle, egal ob sie abweichen oder nicht, analog zum "Mark & use", wenn man direkt beim Benchen aggregiert.
"Excluding outliers" nutzt nur diejenigen, die nicht rot markiert sind, beim automatischen Aggregieren müsste man in dem Fall die Runs wiederholen bis man auf seine gewünschte Anzahl ohne rote Markierungen kommt, beim nachträglichen werden dann halt einfach weniger Runs benutzt, wenn davon welche rot sind.
Hat man überhaupt keine rot markierten Runs in der Tabelle, ist das Ergebnis immer das gleiche, egal welchen der beiden Buttons man drückt**.
Das normale bzw optimale Vorgehen ist daher eigentlich ohne Ausreißer, weil einzelne abweichende Runs ja darauf schließen, dass diese außerhalb der Norm sind(z.B. weil Windows im hintergrund gerade mal Schluckauf hatte) und nicht zur Bewertung verwendet werden sollten.
Gilt zumindest immer dann, wenn man wirklich 5x die gleiche Szene getestet hat und 4 innerhalb der Toleranz sind und einer abweicht.
**Die Tooltips erklären die beiden Buttons eigentlich hinreichend, jedoch kam mir beim Schreiben gerade trotzdem die Idee, dass ich, wenn es sowieso keine Ausreißer in der Tabelle gibt, auch einfach nur einen einzigen Aggregate Button anzeigen lassen könnte und die beiden Optionen erst einblende, wenn ein ausreißer drin ist.
@Taxxor Nein, ich meinte das schon so, dass dann die Werte die über die 3% (oder wie viel Abweichung man zulässt) dann mit in die Aggregation aufnimmt.
Bei Einzelmessungen also genauso wie bei drei hintereinander gemachten, war etwas doof ausgedrückt von mir, aber du hast ja die Erklärung bereits geliefert.
Deswegen sind ja auch damals die Community Benchmarks mit der automatischen Aggregation gefordert worden, da einzelne Messungen eventuell mit der Funktion hinterher zusammengefügt werden konnten obwohl eine hohe Abweichung vorlag (geht ja auch wenn bei einigen Spielen das shader laden länger dauerte und dadurch höhere Werte lieferte).
Deswegen sind ja auch damals die Community Benchmarks mit der automatischen Aggregation gefordert worden, da einzelne Messungen eventuell mit der Funktion hinterher zusammengefügt werden konnten obwohl eine hohe Abweichung vorlag
Deshalb hat mich dein Satz ja so verwirrt, weil das ja genau die Option "excluding outliers" ist.
Including wäre ja die Ausreißer einfach drin zu lassen und das sollte eigentlich nicht das normale Vorgehen sein.
Ich indexe aus aktuellem Anlass mal wieder die Radeon RX 7700 XT und da fiel mir auf, dass ich ums Verrecken keine Power-Werte (Overlay & Sensoren) rausbekomme. GPU-Z meldet artig 230 Watt Boardpower. Ist euch eine (ADL-)Änderung bekannt, die das verursachen kann? Installiert sind die neue AS 24.2.1 sowie der ganz frisch signierte RTSS.
Hallo Freunde der Nacht, bin grad aus dem Resturlaub zurück, frisch am Benchwerk und ich hab euch da was mitgebracht.
Frei nach Captain Hollywood: "More and More and More, I don't know where we're going to ♫♪"
Dieses Mal UE5(.3.2) in Nightingale. Radeon Software 24.2.1.
RX 7900 XTX (Asrock Taichi, aber das sollte ja im Grunde keinen Unterschied machen.
Interessant: Nur GPU Mem Used vom Ewigen Wachstum betroffen, GPU Mem ist offenbar korrekt. Die Sensor-Daten im Übrigen offenbar auch, nur die Anzeige im Overlay wächst und wächst und wächst.
Ich kann mich darum herum organisieren, für mich also kein Drama. Aber vielleicht trotzdem noch ein mal einen Blick wert^^
Ich indexe aus aktuellem Anlass mal wieder die Radeon RX 7700 XT und da fiel mir auf, dass ich ums Verrecken keine Power-Werte (Overlay & Sensoren) rausbekomme. GPU-Z meldet artig 230 Watt Boardpower. Ist euch eine (ADL-)Änderung bekannt, die das verursachen kann? Installiert sind die neue AS 24.2.1 sowie der ganz frisch signierte RTSS.
ich habe hier gerade eine RX 7900 XTX laufen mit Adrenalin 24.2.1. Ich bekomme alle Sensoren angezeigt, siehe Screenshot. Benutzt du vielleicht den ADL Fallback, siehe Settings? Installiere mal am besten die letzte Beta von unserem Build-Server.
Interessant: Nur GPU Mem Used vom Ewigen Wachstum betroffen, GPU Mem ist offenbar korrekt. Die Sensor-Daten im Übrigen offenbar auch, nur die Anzeige im Overlay wächst und wächst und wächst.
Ich teste seit ein paar Tagen die RX 7900 XTX zusammen mit Avatar: FoP, siehe oben. Knapp über 18GB ist die magische Grenze, dann wird Speicher freigeschaufelt. "GPU Mem Used" kommt übrigens vom Treiber, während die anderen Sensoren Windows Performance Counter sind. Der Wert vom Treiber ist dafür bekannt, je nach Update des Treibers sich gerne mal zickig zu verhalten. Hast du mit DDU alle alten Treiber(reste) deinstalliert? Kannst du das mit anderen Spielen reproduzieren? Ist ein komischer Fehler...
ich habe hier gerade eine RX 7900 XTX laufen mit Adrenalin 24.2.1. Ich bekomme alle Sensoren angezeigt, siehe Screenshot. Benutzt du vielleicht den ADL Fallback, siehe Settings? Installiere mal am besten die letzte Beta von unserem Build-Server.
nope, den Haken beim Fallback habe ich nie angefasst. Mit den anderen Navi-Karten inkl. 7900 GRE hatte ich in den letzten Tagen und Wochen auch keine Probleme, nur mit Navi 32 XL will's nicht. Ich installiere mal euer neuestes Werk und werde nachher berichten.
Nope, den Haken beim Fallback habe ich nie angefasst. Mit den anderen Navi-Karten inkl. 7900 GRE hatte ich in den letzten Tagen und Wochen auch keine Probleme, nur mit Navi 32 XL will's nicht. Ich installiere mal euer neuestes Werk und werde nachher berichten.
Das ist durchaus seltsam, da GPU-Z am Ende auch die ADLX verwendet, soweit ich weiß. Nur zur Klarstellung, die Release v1.7.2 hat einen GPU-Power Bug, welcher mit der Beta v1.7.3 behoben wurde.
Nachtrag: Ist eine neue Version von RTSS erschienen. Vielleicht liegt es ja auch daran. Ich hau das morgen mal auf den Testrechner, dann kann ich ja noch mal Feedback geben...
@Zer0Strat Ich check's morgen gern mal ein wenig genauer und schau auch mal, ob ich das irgendwie behoben bekomme. Das war ja im Grunde ein ganz frisch neu aufgesetztes Windows (inklusive kompletten Festplatten-Wipe, System-SSD ist sogar ganz neu, da war eigentlich gar nix drauf^^ Ich hab allerdings den neuen AMD-Treiber über den alten installiert, mit dem das Phänomen auch auftrat, vielleicht hat sich das also tatsächlich "fortgepflanzt".
Ich werkel bei Gelegenheit mal ein bisschen dran rum, bislang bin ich nicht dazu gekommen (Urlaub und diese Woche war ich bisher mit Online-Artikel und Benchmarks gut beschäftigt; morgen sollte ich aber ein bisschen Zeit haben und ich muss auch noch mit ein paar anderen Radeons rumfuhrwerken, dann kann ich das auch gleich mal mit anderen Modellen gegenchecken - bisher hab ich nur XTXen benutzt und folglich auch nur da beobachten können).
Das ist durchaus seltsam, da GPU-Z am Ende auch die ADLX verwendet, soweit ich weiß. Nur zur Klarstellung, die Release v1.7.2 hat einen GPU-Power Bug, welcher mit der Beta v1.7.3 behoben wurde.
Das war's dann wohl - also der Bug in v1.7.2. Ich hatte da irgendeine Build vom Dezember drauf. Wenige Stunden zuvor hat derselbe Rechner aber mit 'ner RX 6400 alles brav angezeigt. Bei RDNA 2 wird ja nur die GPU-Power ausgegeben, bei RDNA 3 die Boardpower. Hing der Bug irgendwo in dieser Kette? Anyway, mit der 1.7.3 Beta geht's auch mit der 7700 XT, danke!
Das war ja im Grunde ein ganz frisch neu aufgesetztes Windows (inklusive kompletten Festplatten-Wipe, System-SSD ist sogar ganz neu, da war eigentlich gar nix drauf^^ Ich hab allerdings den neuen AMD-Treiber über den alten installiert, mit dem das Phänomen auch auftrat, vielleicht hat sich Aas also tatsächlich "fortgepflanzt".
Ich habe den Code sehr genau analysiert. Eine Kumulation der Werte kann ich zu 99,9% ausschließen. Das muss irgendwas internes im Treiber sein. Aber wie gesagt, ist nicht das erst Mal, dass der Memory Sensor Kapriolen schlägt und dann mit einem neuen Treiber wieder brav richtige Werte meldet.
Ich habe schon mehrfach überlegt, aber immer sind zu viele Projekte "in flight", um genauer zu graben und das Für & Wider abzuklopfen. Kannst du vermitteln?
Wider:
Ihr habt das Elmor Labs und der Anschaffungspreis für das Powenatics ist auch weit höher.
(hatte ich mir nämlich überlegt es mir anzuschaffen, aber der Preis ist einfach zu hoch für mich als Privatmensch oder benötogt man das "Device" nicht?)
Für:
Ihr habt direkt eine integrierte Erfassung der Daten mit CX während der einzelnen Runs.
.gif "sm_B-) :-)")
