TE
TE
gaussmath
Guest
Mein Gesicht?? 
TE
TE
gaussmath
Guest
So, jetzt mal wieder zu den ernsten Dingen des Lebens. Bei dem Treffen haben sich ein paar Punkte ergeben, die wir nun eingebaut haben. Es gibt eine neue Version: Release CapFrameX v1.4.2 . DevTechProfile/CapFrameX . GitHub
Es sind im Grunde nur ein paar Kleinigkeiten. Wer Probleme mit Crashes in Verbindung mit dem Overlay hat, der sollte die Version installieren. Außerdem sind die Hotkeys nun völlig frei konfigurierbar.
Es sind im Grunde nur ein paar Kleinigkeiten. Wer Probleme mit Crashes in Verbindung mit dem Overlay hat, der sollte die Version installieren. Außerdem sind die Hotkeys nun völlig frei konfigurierbar.
Zuletzt bearbeitet von einem Moderator:
PCGH_Manu
Redakteur
An den Captain CapFrameX,
zunächst mal ein Riesenlob. Das Tool ist der beste Frame Logger überhaupt! Endlich kein händisches Pfuschen mehr in den CSVs, es schlägt in Sachen Komfort alle anderen Logger um Längen!
Zu Sache: Ich bin gerade dabei, herauszufinden, ob mir das Teil auch bei den Monitortests helfen kann. Du meintest, man sieht die synchronisierten Frames. Habe eben bisschen rumgeloggt und hätte da gleich paar Fragen.
Habe sowohl mit dem G-Sync-Pendel als auch in Overwatch je zwei Durchläufe geloggt - je einmal ohne (G- oder V-)Sync und einmal mit G-Sync. Ich konnte im Synchronisation-Tab keinen Unterschied feststellen, egal ob G-Sync an oder aus. Heißt: Der "Display Changed Times" liegt immer ausnahmslos relativ nah an den Frametimes. Im Tool habe ich die Range auf 1-165 Hz gesetzt, da in dieser am Gerät auch G-Sync funktioniert. Fps habe ich im Pendel schwanken lassen und in Overwatch auf 120 Fps limitiert. Habe jedes Mal drauf geachtet, ob G-Sync entsprechend (de-)aktiviert ist und es am (fehlendem bzw. vorhandenem) Tearing auch festmachen können.
Nu aber meine Fragen:
Hätte es mit und ohne G-Sync nicht Unterschiede in den Graphen geben müssen?
Was genau sind die "Display Changed Times"?
In der Input Lag Analyse lag der Lag mit und ohne G-Sync auch recht nah beieinander, was an sich auch logisch ist, da G-Sync kaum bis keinen Lag verursacht. Aber:
- Was genau wird beim "Input Lag" ausgelesen?
Allgemein gefragt: Wie kann das Tool die VRR-Qualität (oder auch jede andere Monitor-Funktion) bewerten?
Danke schon mal!
Manu
zunächst mal ein Riesenlob. Das Tool ist der beste Frame Logger überhaupt! Endlich kein händisches Pfuschen mehr in den CSVs, es schlägt in Sachen Komfort alle anderen Logger um Längen!
Zu Sache: Ich bin gerade dabei, herauszufinden, ob mir das Teil auch bei den Monitortests helfen kann. Du meintest, man sieht die synchronisierten Frames. Habe eben bisschen rumgeloggt und hätte da gleich paar Fragen.
Habe sowohl mit dem G-Sync-Pendel als auch in Overwatch je zwei Durchläufe geloggt - je einmal ohne (G- oder V-)Sync und einmal mit G-Sync. Ich konnte im Synchronisation-Tab keinen Unterschied feststellen, egal ob G-Sync an oder aus. Heißt: Der "Display Changed Times" liegt immer ausnahmslos relativ nah an den Frametimes. Im Tool habe ich die Range auf 1-165 Hz gesetzt, da in dieser am Gerät auch G-Sync funktioniert. Fps habe ich im Pendel schwanken lassen und in Overwatch auf 120 Fps limitiert. Habe jedes Mal drauf geachtet, ob G-Sync entsprechend (de-)aktiviert ist und es am (fehlendem bzw. vorhandenem) Tearing auch festmachen können.
Nu aber meine Fragen:
Hätte es mit und ohne G-Sync nicht Unterschiede in den Graphen geben müssen?
Was genau sind die "Display Changed Times"?
In der Input Lag Analyse lag der Lag mit und ohne G-Sync auch recht nah beieinander, was an sich auch logisch ist, da G-Sync kaum bis keinen Lag verursacht. Aber:
- Was genau wird beim "Input Lag" ausgelesen?
Allgemein gefragt: Wie kann das Tool die VRR-Qualität (oder auch jede andere Monitor-Funktion) bewerten?
Danke schon mal!
Manu
TE
TE
gaussmath
Guest
Erstmal grundsätzlich ein Schaubild zur Render-Pipeline:
Was wir (bzw. PresentMon) abgreifen ist T_display. Dieser Timestamp bildet die "Display Changed Times" ab. Das sind jene Latenzen, mit welcher der Bildschirm mit Refresh Befehlen befeuert wird. Was dann letztlich nach hinten raus passiert, ist was völlig anderes. Es gibt keine Presents/Timestamps, die das erfassen können.
Ja, das hättest du sehen müssen. Das wird daran liegen, dass G-Sync noch aktiv war. Manchmal muss man neustarten, damit das überhaupt erst wirksam wird.
Hier ein Graph mit inaktivem Sync-Prozess. Die Display Changed Times verteilen sich auf ganzzahlige Teiler von 120Hz. Bei mir ist G-Sync nur im Vollbildmodus aktiv.
Und nun ein Aufnahme im Vollbildmodus. Der Kurvenverlauf ist adaptiv. Man kann die Graphen im Grunde gar nicht voneinander abgrenzen.
Es wird eine Annäherung berechnet. Diese bezieht sich auf Vorgänge innerhalb der Render-Pipeline. Periphäre Latenzen werden nicht abgedeckt. Dafür haben wird den Offset.
Formel:
LatencyMs =~ MsBetweenPresents + MsUntilDisplayed - previous(MsInPresentAPI)
Du kannst bewerten, wie der VRR-Prozess die Befehle an den Monitor raushaut. Zusätzlich kannst du die synced Frames gegen die dropped Frames stellen. Die Analyse bietet die Korrelation und den valid sync Range Counter in %.
Zuletzt bearbeitet von einem Moderator:
PCGH_Manu
Redakteur
Okay, danke schon mal! Dachte ich mir, dass das G-Sync-Pendel hin und wieder lügt. 
Aber Overwatch hatte ich zwische G-Sync an und aus neugestartet, spätestens da hätte ich einen anderen Graphen sehen müssen.
Der Viewsonic XG270QG ist wohl mit seinem Nvidia Scaler zu gut. Werde morgen ein Billig-Modell anstecken, das angeblich im VRR mehr Zicken macht. Und melde mich, falls ich diese nicht im Graphen sehe.
Aber Overwatch hatte ich zwische G-Sync an und aus neugestartet, spätestens da hätte ich einen anderen Graphen sehen müssen.Der Viewsonic XG270QG ist wohl mit seinem Nvidia Scaler zu gut.
Werde morgen ein Billig-Modell anstecken, das angeblich im VRR mehr Zicken macht. Und melde mich, falls ich diese nicht im Graphen sehe.
HisN
Trockeneisprofi (m/w)
Quadchannel, Dualchannel, Singlechannel? WTF?
Wir alle wissen ja, das Singlechannel etwas Performance im CPU-Limit kostet und Dualchannel etwas Performance im CPU-Limit bringt. Und wer hätte das gedacht. Selbst mit Quadchannel skalieren die Games im CPU-Limit.
War einfach mal interessant zu sehen.
Speicher-Durchsatz Single-Channel, Dualchannel, Quadchannel auf einem 3960X mit billig Ripjaw V 3.2Ghz CL16 auf 3.6Ghz CL19 gezogen. Dabei kommt es mir nicht auf die absolute Performance an, sondern auf die Differenz der Werte. Was passiert wenn man anstatt 25GB/Sec immerhin 50GB/sec oder sogar fette 100GB/Sec Copy aus dem Speicher ziehen kann.
Gebencht in 720p/Ultra und darauf geachtet das meine Graka nie 90% Last wesentlich überschritten hat. Es wurde also wirklich nur die reine CPU-Leistung abgerufen. 4 Durchläufe. Der erste zum Aufwärmen und dann drei mal gezeitet.
Danke für das Tool.gif "sm_B-) :-)")
Wir alle wissen ja, das Singlechannel etwas Performance im CPU-Limit kostet und Dualchannel etwas Performance im CPU-Limit bringt. Und wer hätte das gedacht. Selbst mit Quadchannel skalieren die Games im CPU-Limit.
War einfach mal interessant zu sehen.
Speicher-Durchsatz Single-Channel, Dualchannel, Quadchannel auf einem 3960X mit billig Ripjaw V 3.2Ghz CL16 auf 3.6Ghz CL19 gezogen. Dabei kommt es mir nicht auf die absolute Performance an, sondern auf die Differenz der Werte. Was passiert wenn man anstatt 25GB/Sec immerhin 50GB/sec oder sogar fette 100GB/Sec Copy aus dem Speicher ziehen kann.
Gebencht in 720p/Ultra und darauf geachtet das meine Graka nie 90% Last wesentlich überschritten hat. Es wurde also wirklich nur die reine CPU-Leistung abgerufen. 4 Durchläufe. Der erste zum Aufwärmen und dann drei mal gezeitet.
Danke für das Tool
Anhänge
TE
TE
gaussmath
Guest
Danke für das Tool
Dabei habe ich AIDA64 gar nicht programmiert...
Edit: Aber beeindruckend die Werte, insbesondere F1 2019. Eigentlich hieß es immer, dass Quad-Channel in Games nichts bringt.
Zuletzt bearbeitet von einem Moderator:
Ich habe zu den VRR und der Synchronisation auch noch was einzuwerfen.
Das Problem ist wahrscheinlich die Art und Weise wie PresentMon die Display Change Time ausliest. Nämlich immer mit den Buffer Swap der Grafikkarte. Ohne vsync ist das nicht limitiert, kann also so oft wie es nur geht swapen. Wenn so ein Swap während der Übertragung des Bildes geschieht, gibt es halt hässliches Tearing, da ein Teil des Bildes aktueller als ein anderer Teil ist.
Bei Vsync werden die Buffer Swapes immer getimed ausgeführt, sodass es während der Übertragung nicht zu Tearing kommen kann.
Adaptive Sync passt die tatsächliche Displaytime den Buffer Swapes an, sodass auf diese Weise kein Tearing entsteht.
Im Normalfall sieht die Kurve zwischen keinerlei Sync und adaptive Sync also sehr ähnlich aus, da auf die tatsächliche Displayfrequenz nicht zugegriffen wird.
Ich weiß nicht was der Flag allows Tearing in der Aufnahme Datei auch bei adaptive sync funktioniert. Denn mit meinen Tripple Buffering Setup wird hier gesagt, dass es kein Tearing gibt. Ohne Sync sagt es jedoch, dass es Tearing geben kann. Wenn das auch bei adaptive Sync, insbesondere in den Grenzbereichen funktionieren würde, könnte man damit wahrscheinlich VRR Tests machen.
Da ich aber eine 980TI mit einen Monitor mit Freesync (bzw. adaptive Sync) betreibe komme ich nicht in den Luxus das auszuprobieren..
Das Problem ist wahrscheinlich die Art und Weise wie PresentMon die Display Change Time ausliest. Nämlich immer mit den Buffer Swap der Grafikkarte. Ohne vsync ist das nicht limitiert, kann also so oft wie es nur geht swapen. Wenn so ein Swap während der Übertragung des Bildes geschieht, gibt es halt hässliches Tearing, da ein Teil des Bildes aktueller als ein anderer Teil ist.
Bei Vsync werden die Buffer Swapes immer getimed ausgeführt, sodass es während der Übertragung nicht zu Tearing kommen kann.
Adaptive Sync passt die tatsächliche Displaytime den Buffer Swapes an, sodass auf diese Weise kein Tearing entsteht.
Im Normalfall sieht die Kurve zwischen keinerlei Sync und adaptive Sync also sehr ähnlich aus, da auf die tatsächliche Displayfrequenz nicht zugegriffen wird.
Ich weiß nicht was der Flag allows Tearing in der Aufnahme Datei auch bei adaptive sync funktioniert. Denn mit meinen Tripple Buffering Setup wird hier gesagt, dass es kein Tearing gibt. Ohne Sync sagt es jedoch, dass es Tearing geben kann. Wenn das auch bei adaptive Sync, insbesondere in den Grenzbereichen funktionieren würde, könnte man damit wahrscheinlich VRR Tests machen.
Da ich aber eine 980TI mit einen Monitor mit Freesync (bzw. adaptive Sync) betreibe komme ich nicht in den Luxus das auszuprobieren..
Anhänge
Zuletzt bearbeitet:
Ich habe gestern einen Prozessor mit CapFrameX geindext. Dabei habe ich mein Feedback und das der anderen zusammengetragen.
PCGH-Feedback CapFrameX V1.42 Stand 13.02.2020
Ob das Overlay Leistung kostet, konnte ich noch nicht ausreichend prüfen. Bisher gefällt mir die Bedienung und vor allem die Zeitersparnis aber sehr gut, es war unheimlich bequem und einfach aus dem Comparsion Tab alle Werte in den Index einzutragen, ohne auch nur einmal den Taschenrechner zücken zu müssen.
PCGH-Feedback CapFrameX V1.42 Stand 13.02.2020
- Wenn bei Start der Software die Run History bereits aktiviert ist, ist diese im Overlay aber trotzdem nicht aktiv und ausgegraut. Erst nach beenden und nochmaligen aktivieren der Run History lässt sich das Overlay aktivieren (möglicherweise passiert das auch nur, wenn man es in der bestehenden Installation so einstellt und die neue dann drüber installiert)
- Overlay in Forza Horizon 4 funktioniert nicht (dürfte eher ein Problem von RTSS sein?)
- Es ist nach Installation der V1.42 einmalig bei Zombie Army 4 unter Vulkan passiert, dass CapframeX den ersten Run korrekt aufzeichnet, die verbleibend anderen beiden aber einfach nicht mehr startet, trotz aktiven Tool, ausgewähltem korrekten Prozess und korrekten Druck auf den Capture-Hotkey. Nach einem Neustart ist das dann bisher nicht wieder passiert. Musste sich vielleicht erst "einrenken"
- Wenn eine veraltete Version von RTSS genutzt wird, stürzt CapFrameX bei Klick auf Neubelegung des Capture-Hotkey und der Capture-Time ab, Gründe unbekannt
- Wunsch: Wenn ich einen Index-Durchlauf beendet habe, bin ich gezwungen, die Capture-Dateien aus dem Dokumente-Ordner auszuschneiden, wenn ich direkt danach mit anderen CPUs weitermachen möchte, damit die Übersicht erhalten bleibt. Ist es möglich, im Übersichtsfenster der Runs "Ordner"/Gruppen zu erstellen? Die heißt dann beispielsweise "Core i7-8700K" und wenn ich die aufklappe, offenbaren sich mir alle durchgeführten Runs, die ich mit der CPU gemacht habe. Das könnte man wahlweise mit dem Namen der CPU automatisieren, alternativ den User selbst anlegen lassen. Dafür müsste es möglich sein, bestehende Runs zu verschieben.
- Wunsch: Berücksichtigst du ja bereits: Weitere Parameter für das Overlay, darunter vor allem die Package Power für unsere Zwecke ^^ Dazu eine Log-Funktion mit automatisierter Auswertung des Durchschnitts(verbrauchs), solange das Spiel läuft.
Ob das Overlay Leistung kostet, konnte ich noch nicht ausreichend prüfen. Bisher gefällt mir die Bedienung und vor allem die Zeitersparnis aber sehr gut, es war unheimlich bequem und einfach aus dem Comparsion Tab alle Werte in den Index einzutragen, ohne auch nur einmal den Taschenrechner zücken zu müssen.
TE
TE
gaussmath
Guest
@Dave: Danke, das nenne ich mal ein Feedback. 
Der beiden Wünsche sind schon genau so eingeplant, siehe Issues auf GitHub. Die anderen Sachen schaue ich mir an.
Der beiden Wünsche sind schon genau so eingeplant, siehe Issues auf GitHub. Die anderen Sachen schaue ich mir an.
Zuletzt bearbeitet von einem Moderator:
TE
TE
gaussmath
Guest
Ja gaussmath ist auch immer noch eine GPU/CPU Auslastungsaufzeichnung schuldig!
Kannst gerne schon mal ein Konzept entwickeln, wie das ganze später visualisiert werden soll. Stell dir mal vor, HisN will die Auslastung von 48 Threads zeichnen. ^^
Eine kurze Frage. Dieser Graph ist also nicht im Vollbildmodus entstanden, sondern in Borderless oder Windowed?
Wenn ja ist Tripple Buffering Vsync von den Windows Desktop mit dabei.
Taxxor
Freizeitschrauber(in)
Den Fall hatte ich zwischendurch auch mal beim debugen. Ich denke das kommt wenn man vorher die History aktiviert hatte und dann eine neue Version drüberinstalliert.
Es wird zwar in der userconfig gespeichert, dass man die History aktiviert hat, aber da das Flag für die Liste erst aktiviert und gesetzt wird, wenn man den Toggle aktiviert, muss man das dann erst noch mal machen, danach bleibt es dann aber auch aktiv wenn man neu startet.
Lässt sich aber bestimmt leicht beheben.
TE
TE
gaussmath
Guest
Funktioniert denn Afterburner + RTSS?
Nein, auch nicht. (Schiebe es daher auch auf RTSS)
TE
TE
gaussmath
Guest
Cloud-Anbindung incoming... Zusätzlich arbeiten wir an der Integration von Sensordaten. CX ist auf dem Weg, das innovativste und umfangreichste Capture und Analyse Tool überhaupt zu werden.
Ähnliche Themen
