PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Realtime Capturing der Frametimes


Grestorn
2015-04-01, 11:13:16
Kennt jemand eine Methode, die Frametimes in Echtzeit zu capturen?

Also in etwa so wie in den Eurogamers.net Videos: https://www.youtube.com/watch?v=9bDmF50Y10U

Mir ist klar, dass die professionelle Capturing Hardware nutzen und die Overlays nachträglich in die Videos einblenden. Das Ergebnis ist dann schon sehr beeindruckend... Aber irgendwie müsste man das doch auch so nachbilden können.

Mit MSI Afterburner kann ich mir auf dem zweiten Schirm die Frametimes in nahezu Echtzeit anzeigen lassen (Capturing Rate 100ms). Das ist ganz ok, aber ich kenne keine Möglichkeit, den zweiten Screen in Echtzeit zusammen mit dem Spielgeschehen zu capturen (zumal das ja auch ziemliche Bandbreiten-Verschwendung wäre).

Afterburner erlaubt zwar, die Frametimes auch im OSD anzuzeigen, dort aber nur als Zahlenwert und nicht als Graph und auch nur mit einem Refresh von vielleicht 500ms.

Gibt es denn wirklich kein Tool, mit dem man ein OSD mit einem Frametime-Graph einblenden kann? Eine echte Marktlücke... :)

Kartenlehrling
2015-04-01, 11:56:39
MPC-HC biete es doch an.

HisN
2015-04-01, 12:46:45
Die Frametimes als Zahl vom OSD vom Afterburner möchtest Du nicht haben? Es soll ein Graph sein?

Edit: Wer lesen kann^^

Demirug
2015-04-01, 13:04:37
Eine Marktlücke ist es nur wenn es auch genügend Leute gibt die Zusammen genug dafür bezahlen das es sich lohnt sowas zu entwickeln.

Die echten Frametimes kannst du sowieso nicht wirklich messen. Nur die Abstände zwischen den entsprechenden "End Frame" calls von der CPU.

Wenn man bereits einen Famework hat um sich in ein API einzuklinken um irgendein OSD anzuzeigen wäre es nicht sonderlich schwer das entsprechend zu erweitern.

So ein Framework selbst ist aufgrund der vielen derzeit aktiv genutzten 3D APIs (meist auch noch 32 und 64 bit) inzwischen leider etwas mehr arbeit geworden

Grestorn
2015-04-01, 13:26:35
Eine Marktlücke ist es nur wenn es auch genügend Leute gibt die Zusammen genug dafür bezahlen das es sich lohnt sowas zu entwickeln.Ich wäre schon bereit, etwas dafür zu zahlen, aber es müssten nichts desto trotz einige mehr zusammenkommen, damit man das finanzieren könnte.

Die echten Frametimes kannst du sowieso nicht wirklich messen. Nur die Abstände zwischen den entsprechenden "End Frame" calls von der CPU.Ja, das ist leider klar. Dafür bräuchte man wohl so etwas wie einen Callback-Hook im Treiber, der es einem erlauben würde, den Zeitpunkt, an dem das Bild tatsächlich zum Monitor übertragen wird, zu erfassen.

Wenn man bereits einen Famework hat um sich in ein API einzuklinken um irgendein OSD anzuzeigen wäre es nicht sonderlich schwer das entsprechend zu erweitern.

So ein Framework selbst ist aufgrund der vielen derzeit aktiv genutzten 3D APIs (meist auch noch 32 und 64 bit) inzwischen leider etwas mehr arbeit geworden
Für Unwinder (-> Afterburner & Co.) oder den Leuten von FRAPS wär das ein Klacks, die haben das ja alles schon.
Ich hab mal vor einigen Jahren nen D3D-Hook auf Madshi's (madshi.net) Bibliothek aufgebaut, aber da fehlt es weit zu einem wirklich nutzbaren Framework, das eben, wie Du schon sagst, auch mit 64 bit, DX11 usw. klar kommt.

MPC-HC biete es doch an.
Woher kommt der Graph in Deinem Screenshot? Und was zeigt der genau?

KiBa
2015-04-01, 14:27:11
Als ich früher den SLI-Harmonizer entwickelt habe (oder zumindest versucht), habe ich festgestellt, dass die "End Frame" Calls denkbar ungeeignet dafür sind, Frametimes zu messen. Bei einigen Treiberversionen (Nvidia) ging das ganz gut, da hat z.B. in D3D9 der Present-Call blockiert. Dann habe ich die Treiber geupdated und schon gab es Wartezeiten in beliebigen D3D-Funktionen und Present war plötzlich immer ganz schnell fertig. Die Calls können offenbar gecached werden und selbst bei einer Prerender-Queue der Größe 1 kann der Treiber wohl noch auf verschiedene Calls des nächsten Frames warten.

Hinzu kommt bei aktuellen NVidia-Treibern ein sehr komisches Verhalten im Fullscreen-Mode (welches vielleicht mit obigem Verhalten zusammenhängt): Die vom Programm gemessenen Frametimes schwanken sehr stark bei zwei aufeinander folgenden Frames. Im Mittel über 2-3 Frames stimmt es dann wieder. Glättet die Anwendung da nicht, kann es verschiedene böse Feedback-Probleme und eine Verstärkung der Schwankungen geben. Vielleicht auch ein Grund, warum viele Spiele immer öfter einen Borderless-Mode wählen (der ironischerweise auch noch die Input-Latenz senkt).

Also ich sehe mit Hooks da nicht viele Chancen. Entweder es muss ne eigene Hardware her oder das Tool muss sich tief ins Betriebssystem oder gar die Treiber eingraben, falls das überhaupt möglich ist.

del_4901
2015-04-01, 14:32:38
Die echten Frametimes kannst du sowieso nicht wirklich messen. Nur die Abstände zwischen den entsprechenden "End Frame" calls von der CPU.
Wenn man eh ein overlay zeichnet kann man auch gleich einen TimerEvent in die GPU schieben und die timings ziehmlich genau (abgesehen vom Monitor) annaehern.

KiBa
2015-04-01, 19:39:02
Wenn man eh ein overlay zeichnet kann man auch gleich einen TimerEvent in die GPU schieben und die timings ziehmlich genau (abgesehen vom Monitor) annaehern.
Ah, interessant. In DXGI soll es eine Funktion geben, um den exakten vsync-Zeitpunkt eines Frames zu bekommen. Wäre das hierfür zu gebrauchen und würde es gleiche Ergebnisse wie mit den TimerEvents liefern?

del_4901
2015-04-02, 10:26:06
Die vBlanks bekommt man einfacher und genau mit dem ETW framework.