CapFrameX - Capture und Analyse Tool

[ZeroStrat]

@Taxxor Was ist unsere Empfehlung für die "Related metric" und warum?

 

[Taxxor]

Ich würde sagen P1 weil man da eine gute Basis für einen Vergleich hat. Bei P0.2 ist man schon je nach Aufnahmelänge und average FPS im Bereich von 4-5 Frames, das ist schon recht wenig, zumindest wenn man das auf 3% abfragen will.

Alternativ dazu eben der 1% low average.

Ist halt sehr nach Spiel abhängig, ein Kingdom Come könnte ich mit P0.2 und erst Recht mit 0.1% low meist vergessen, wenn ich nicht 10% Toleranz einstellen würde.
Bei einem Wichter 3 könnte ich hingegen auch 0.1% low auf 2% Abweichung abfragen und hätte keine Probleme.

P1 und 1% low sind da schon ein guter Mittelweg, da bleibt es dem Nutzer überlassen, ob er P1 nehmen will, welcher insgesamt stabiler ist, oder 1% low average, welcher die Ausreißer stärker gewichtet.

Von unserer Seite würde ich P1 und 3 oder 4% mitgeben.

(Die Amis werden sich sowieso alle 1% low und 0.1% low als Metriken einstellen^^)

 

[ZeroStrat]

@Taxxor Das klingt rund. 👍

Hab übrigens mal auf Twitter gefragt, ob's C# Wrapper für AMD's AGS Lib gibt. Schweigen im Walde...

 

[Taxxor]

Das ist alles so undurchsichtig, es gibt ja auch noch AMD ADL, womit man laut google angeblich GPU load auslesen könne, sehe ich aber in der doku auch nix von

 

[ZeroStrat]

OCAT integriert ja auch AGS. Also sollte das auch die Lib unserer Wahl sein.

 

[Taxxor]

Die lesen aber keine Last aus^^ Keine Ahnung ob das auch mit der AGS geht.

 

[ZeroStrat]

Hab's in den Untiefen von GPUOpen gefunden:

 PRINTF("odNPerformanceStatus.iGPUActivityPercent : %d\n", odNPerformanceStatus.iGPUActivityPercent);

Der Haken ist bei den Taktraten ist, dass es current/dynamisch und deskriptiv gibt, die aber nicht in der verlinkten Lib angeboten werden, so wie es scheint. Wir werden also mehrere Quellen einbinden müssen, auch weil die Treiberversion dort nicht zu finden ist.

 

[ChrisMK72]

Ultrageil, wie das tool wird.

Will das nicht nach jedem posting schreiben, daher mach ich das nur ab und zu mal(ich bremse mich, damit die wichtigen Infos nicht untergehen ), aber ich bin begeistert !
(Auch was die run history usw. angeht und überhaupt wie es immer besser wird, auch in Details und so)

 

[Taxxor]

Wir werden also mehrere Quellen einbinden müssen, auch weil die Treiberversion dort nicht zu finden ist.

Das was du verlinkt hast ist ja auch die ADL und nicht AGS^^
Ich mache gleich mal ne Ausnahme mit OCAT und schaue mal, ob die mir den Treiber ausspuckt.

Ergänzung (17. Januar 2020)

Eine ältere Datei von November 2019

Base Driver Version 19.30.31.15-191112a-348545E-RadeonSoftwareAdrenalin2019

Ist halt nicht so ganz die Info, die man haben will. Wenn ich das mit meinem aktuellen Stand vergleiche, habe ich die 19.12.1 drauf und die Treiberversion sagt 19.30.31.20-191126a.

Wonach man als AMD Nutzer eigentlich suchen müsste wäre die Radeon Software Version.
Müsste man die nicht vielleicht sogar aus der Registry rausbkeommen?

Und OCAT liest übrigens auch korrekt aus, das ich eine RX Vega 56 habe, während CX nur RX Vega schreibt.
Das RX Vega steht auch so in der Registry drin.
Und die "ReleaseVersion" wäre die genaue Treiberversion, ich würde mich aber an die "ExternalReleaseVersion" halten, oder die "RadeonSoftwareVersion", das scheint das gleiche zu sein.

 

[ZeroStrat]

aber ich bin begeistert !

Chris, so geht das nicht weiter. Du musst auch mal was kritisieren.

 

[Taxxor]

Hier ein Text der Option "Input Lag reduction" von The Division 2, getestet mit unserer neuen Input lag approximation.

Laut Text soll es den Input lag verringern aber dabei eventuell Einfluss auf die FPS haben.
Im Test konnte ich letzteres nicht feststellen, die FPS waren in beiden Fällen absolut gleich, die Frametimes mit aktivierter Option sogar um einiges ruhiger als ohne.

Beim Input Lag hat sich aber tatsächlich was getan:

Input Lag Reduction OFF

Input Lag Reduction ON

 

[ZeroStrat]

RodroG hat übrigens mal seine Specs auf den Tisch gepackt.
Monitor: 4ms
Mouse/Keyboard: 1-2ms

Hab's überprüft, passt! Ich glaube, wir sind mit unseren 20ms default a bissle zu streng.

 

[Taxxor]

Ich bin mir bei den Daten aus dieser Datenbank da immer noch nicht sicher, ob die Response time zum Input lag dazugehört oder nicht.

Und wenn ich da die Tests mit Kamera sehe wo eigentlich alle Games zwischen 60 und 80ms haben, sind selbst die Werte mit unseren 20ms viel niedriger.

Mein Monitor soll 6ms Input Lag haben und eine Refresh time von 4-20ms.
Wenn es 6ms dauert bis das Bild beim Monitor ankommt, dann muss es danach doch immernoch erstmal angezeigt werden, dann kommt doch die Refresh time eigentlich oben drauf.
Also wären das bei mit 10-26ms

 

[ZeroStrat]

Hier mal die Definition:

Input lag deckt das doch alles ab. Die Frage ist ja auch, wie genau solche Kameramessungen sind.

 

[Taxxor]

7ms macht bei einem 144Hz Panel ja auch Sinn, schneller kann es ja gar nicht reagieren.
(Daher finde ich die angeblichen minimalen 4ms bei mir auch merkwürdig)


Also das Display aktualisiert sich alle 7ms bzw mit Freesync eben je nachdem wie meine FPS sind.
Sende ich dann etwas hin, dauert es 4ms bis es ausgegeben werden kann. Je nach Zeitpunkt gibt es dann im besten Fall gerade einen Refresh oder im schlechtesten Fall erst nach 7ms.

Im Schnitt müsste also die halbe Reaktionszeit mit drauf kommen.
Die Kombi daraus heißt dann wohl "Display Lag"

 

[ZeroStrat]

Hmm, dann böte sich noch die durchschnittliche Reaktionszeit an.

 

[Taxxor]

Also ich glaube mit 10ms sind wir gut dabei.
Jetzt wo ich auch mal Benches im GPU Limit gemacht habe, also eher im Bereich 50-60fps bin, sind die damit auch alle bei 40-70ms

 

[Haldi]

Input Lag Reduction OFF
Anhang anzeigen 866754

Input Lag Reduction ON
Anhang anzeigen 866755

Also die beiden Graphen sehen ja exakt genau gleich aus Beide 4cm über der grünen Linie. ich sehe da keinen Unterschied.


P.S..

Ich finde die Verteilkurve als Barchart ja eigentlich gar nicht schlecht.... mit 15 Pillars sogar recht fein gegliedert...
Aber ist ist halt einfach keine "Kurve"

Ich persönlich find sowas wie eine Linie mit Punkte wesentlich besser.

(Natürlich sollte in demfall die Linie korrekt sein und nicht Interpoliert wie hier in Excel...)

Aber was ist so die Öffentliche Meinung zu dem Thema?

 

[Taxxor]

Also die beiden Graphen sehen ja exakt genau gleich aus Beide 4cm über der grünen Linie. ich sehe da keinen Unterschied.

Soll das ein Hinweis darauf sein, dass wir dort auch eine feste y-achsen Skalierung einbauen sollen?

Ergänzung (18. Januar 2020)

Ich finde die Verteilkurve als Barchart ja eigentlich gar nicht schlecht.... mit 15 Pillars sogar recht fein gegliedert...
Aber ist ist halt einfach keine "Kurve"

Das liegt daran dass es keine Verteilerkurve sondern ein Histogramm ist. Die haben immer bar charts

 

[ChrisMK72]

Du musst auch mal was kritisieren.

Nix zu meckern.
(bekanntlich Deutschlands größtes Lob ! )