Grafikkarten Grundlagenartikel Praxis Testberichte

Blick ins Lab: Renderzeit, Zeit zwischen tatsächlichen Bildänderungen und Varianzen bei Benchmarks richtig erfassen

Um die Leistung von Grafikkarten präzise zu erfassen, ist der Einsatz spezialisierter Benchmarking-Software unerlässlich. Diese Programme protokollieren anspruchsvolle Grafikprozesse, um die Fähigkeiten der GPU unter realistischen Bedingungen zu testen. Einige der bekanntesten Tools basieren auf PresentMon, einem von Intel entwickelten Low-Level-Tool zur Erfassung von Frame-Präsentationszeiten und anderen Grafikleistungsdaten. PresentMon  ermöglicht die Überwachung von Präsentationsereignissen, die von Grafik-APIs wie DirectX, OpenGL und Vulkan generiert werden. Es erfasst dabei wichtige Metriken wie Frame-Raten, Frame-Zeiten und Latenzen, die für die Analyse der Grafikleistung entscheidend sind. Auf Basis von PresentMon wurden mehrere weiterentwickelte Benchmarking-Programme entwickelt, die eine benutzerfreundlichere Oberfläche und zusätzliche Funktionen bieten.

Viele der führenden Tools zur Leistungsmessung von Grafikkarten basieren auf PresentMon, einem Low-Level-Diagnosewerkzeug, das von Intel entwickelt wurde, um präzise Informationen zu Frame-Präsentationen und deren zeitlichem Ablauf zu erfassen. NVIDIA FrameView ist eines dieser Programme, das PresentMon als Grundlage nutzt, jedoch speziell für GeForce-GPUs optimiert wurde und zusätzliche Funktionen wie GPU-spezifische Datenintegration, visuelle Darstellungen und Optimierungen zur Erhöhung der Messgenauigkeit bietet. Ein weiteres Tool, CapFrameX, hebt sich durch eine benutzerfreundliche Oberfläche hervor, die detaillierte Analysen und Vergleiche von Frame-Zeiten ermöglicht und ebenfalls auf PresentMon aufbaut. OCAT (Open Capture and Analytics Tool), ein Open-Source-Projekt, verwendet ebenfalls PresentMon und richtet sich an Entwickler und Tester, die umfassende Analysen der Grafikleistung über verschiedene APIs hinweg durchführen möchten. Zusätzlich gibt es spezialisierte Werkzeuge wie den PresentMonLauncher, der die Bedienung von PresentMon durch eine einfachere Oberfläche erleichtert und dessen Einsatz insbesondere für Anfänger zugänglicher macht. Jedes dieser Tools zielt darauf ab, die Fähigkeiten von GPUs durch präzise Erfassung und Analyse von Frame-Daten zu bewerten und bietet so eine unverzichtbare Grundlage für Benchmarking und Optimierung in der Welt der Computergrafik. Naja, und dann kamen Blackwell und DLSS4…

Funktionsweise von PresentMon

PresentMon überwacht die Präsentationsereignisse, die von DirectX, Vulkan und OpenGL-basierten Anwendungen generiert werden. Jedes Mal, wenn ein Frame von der Anwendung an die GPU übergeben oder vom Display-Manager dargestellt wird, erfasst PresentMon die relevanten Ereignisse. Zu den erfassten Daten gehören unter anderem:

  • Präsentationszeitpunkte: Wann ein Frame an die GPU-Queue übergeben wurde.
  • Frame-Latenz: Die Zeitspanne zwischen der Übergabe eines Frames und dessen tatsächlicher Darstellung.
  • Frame-Pacing: Gleichmäßigkeit der Darstellung von Frames, um Stottern oder Inkonsistenzen zu identifizieren.
  • API-spezifische Daten: Erfassung von Präsentationen, die über DirectX 9, 11, 12, Vulkan oder OpenGL ausgelöst werden.

Die von PresentMon generierten Logs können zur Analyse mit externen Tools verarbeitet werden. Es ist besonders nützlich für das Debugging und die Optimierung von Anwendungen, da es eine präzise und detaillierte Sicht auf den Ablauf der Frame-Darstellung bietet.

PresentMon als Grundlage für NVIDIAs FrameView

NVIDIA hat PresentMon als technologische Grundlage für das eigene Tool FrameView verwendet, um die Leistung von GeForce-GPUs und kompatiblen Anwendungen zu analysieren. Während PresentMon als generisches Low-Level-Diagnosetool konzipiert ist, erweitert FrameView dessen Funktionen durch eine einfache Oberfläche und zusätzliche Optimierungen, die speziell auf NVIDIA-GPUs abgestimmt sind. Aber FrameView funktioniert natürlich auch mit Intel- und AMD-Grafikkarten.

Erweiterungen von FrameView gegenüber PresentMon:

  1. Integration von GPU-spezifischen Daten: FrameView kombiniert die von PresentMon erfassten Frame-Daten mit hardware-spezifischen Informationen von NVIDIA-GPUs, z. B. GPU-Auslastung, Energieverbrauch und Temperatur.
  2. Verbesserte Visualisierung: Im Gegensatz zu PresentMon, das ausschließlich Log-Daten liefert, bietet FrameView eine grafische Benutzeroberfläche zur Darstellung von Leistungsmetriken in Echtzeit.
  3. Optimierungen für Genauigkeit: NVIDIA hat bekannte Schwächen in PresentMon, wie beispielsweise die Handhabung bestimmter Edge-Cases bei der Messung von MsBetweenDisplayChange, behoben und optimiert, um präzisere Ergebnisse zu liefern.
  4. Erweiterte Kompatibilität: FrameView unterstützt zusätzliche Features wie die Analyse von DLSS-basierten Frame-Generationen und Hardware-beschleunigten Technologien wie Flip Metering, was bei PresentMon nicht direkt implementiert ist.

Die Nutzung von PresentMon als Basis ermöglicht es FrameView, sich auf ein bewährtes und robustes Framework zu stützen, das mit verschiedenen APIs und Plattformen kompatibel ist. NVIDIA hat jedoch FrameView so angepasst, dass es gezielt für die Analyse von GPU-spezifischen Technologien und Optimierungen verwendet werden kann, insbesondere im Kontext von DLSS und Frame-Generierungsalgorithmen. Das betrifft auch DLSS4 und die richtige Erfassung der Render- und Anzeigedaten. PresentMon und FrameView können dabei als komplementäre Werkzeuge betrachtet werden: PresentMon bietet eine universelle und detaillierte Grundlage, während FrameView diese durch benutzerfreundliche Funktionen und NVIDIA-spezifische Optimierungen erweitert, um Entwicklern und Testern eine umfassendere Analyseplattform zu bieten.

Der FTI (Frame Time Interpreter) von igor’sLAB

Und trotzdem generiert dies noch lange keine Chartsgrafiken. Genau deshalb habe ich mir für den internen Gebrauch eine recht flexible Software programmiert, die bereits seit Jahren für meine ganzen Charts die Log-Files aus FrameView (und vorher PresentMon) zweckmäßig und richtig auswerten kann. Warum hier eine wichtige Unterscheidung zu treffen ist, möchte ich heute einmal erklären und begründen. Während die meisten Tools wie CapFrameX  immer noch die Metrik MsBetweenPresents nutzen, muss man einfach mit der Zeit gehen. Denn PresentMon bietet ja in den Log-Dateien noch viel mehr als nur die reine Renderzeit der GPU. Ich nutze hier zwei Metriken aus gutem Grund und ich kann nur hoffen, dass die ganzen Tools spätestens mit Einführung von NVIDIAs MFG ebenfalls nachziehen, denn eigentlich war vieles auch bis heute schon nicht ganz korrekt. Das Bild unten zeigt meine hauseigene Software, die dann brav Karte für Karte meine Excel-Charts füllt (was ich gleich noch zeige):

Die Metriken MsBetweenPresents und MsBetweenDisplayChange sind zwei wichtige Kennzahlen im Bereich der Leistungsbewertung von Grafikprozessoren (GPUs) und spielen eine zentrale Rolle bei der Analyse der Bildausgabeprozesse und deren Auswirkungen auf die Benutzererfahrung. Um den Unterschied zwischen diesen beiden Metriken im Detail zu erklären, ist es notwendig, den gesamten Ablauf der Frame-Generierung und -Darstellung zu betrachten, von der Verarbeitung eines Frames durch die GPU bis hin zur tatsächlichen Anzeige auf dem Bildschirm.

MsBetweenPresents: Zeit zwischen zwei Frame-Präsentationen

Die Metrik MsBetweenPresents misst den Zeitraum zwischen zwei aufeinanderfolgenden Präsentationen eines Frames durch die GPU. Dies geschieht, wenn die GPU ein neues Bild zur Verarbeitung erhält und dieses an die Render-Queue übergibt. Die Metrik ist dabei ein Indikator für die Frequenz, mit der die Anwendung Frames erstellt und der GPU bereitstellt. Das sind die Werte, die ich für die Bewertung der durchschnittlichen FPS zugrunde lege. Betrachten wir mal diesen Modus in meiner Software und merken uns auch die Ergebnisse:

Merkmale von MsBetweenPresents:

  1. Fokus auf die GPU-Queue: Die Metrik misst den Zeitpunkt, an dem ein neuer Frame zur Verarbeitung übergeben wird, unabhängig davon, wann dieser tatsächlich angezeigt wird.
  2. Performance der Anwendung: MsBetweenPresents reflektiert die Effizienz der Render-Pipeline und wie schnell die Anwendung in der Lage ist, Frames zu produzieren und an die GPU weiterzugeben.
  3. Eignung für CPU/GPU-Analysen: Diese Metrik ist besonders hilfreich, um Engpässe zu identifizieren, die durch die Anwendung oder die GPU-Queue entstehen. Wenn z. B. die Anwendung Frames zu langsam liefert, wird MsBetweenPresents steigen, selbst wenn die GPU leistungsfähig ist.

Einschränkung von MsBetweenPresents: MsBetweenPresents berücksichtigt nicht, wann ein Frame tatsächlich auf dem Bildschirm sichtbar wird. Das bedeutet, dass diese Metrik keine Aussage über die Synchronisation mit dem Display oder die wahrgenommene Fluidität durch den Benutzer liefert. Sie ist daher stärker auf die Analyse der Render-Pipeline ausgerichtet.

MsBetweenDisplayChange: Zeit zwischen tatsächlichen Bildänderungen

Die Metrik MsBetweenDisplayChange erfasst den Zeitraum zwischen zwei sichtbaren Änderungen des angezeigten Bildinhalts auf dem Bildschirm. Dies ist der Moment, in dem das Display tatsächlich ein neues Bild ausgibt, das von der GPU fertiggestellt wurde. Ich nutze diesen Wert für die Varianzen und das P1 Low (einschließlich meiner Perzentil-Kurven), weil es genau die Anzeige widerspiegelt. Auch hier noch einmal zur Veranschaulichung die Darstellung im Interpreter und man sieht sehr deutlich, dass das ausgegebene Bild “runder”, also smoother erscheint als es die vorige Kurve der üblichen Programme eigentlich impliziert hat.

Merkmale von MsBetweenDisplayChange:

  1. Fokus auf die Display-Ausgabe: Diese Metrik umfasst nicht nur die Renderzeit, sondern berücksichtigt auch den gesamten Prozess bis zur Darstellung auf dem Bildschirm. Dazu gehört auch die Synchronisation mit der Bildwiederholrate des Monitors.
  2. Bedeutung für die Benutzererfahrung: Sie ist besonders relevant für die Bewertung der wahrgenommenen Fluidität und Bildkonsistenz. Eine niedrige und konsistente MsBetweenDisplayChange-Zeit trägt zu einem flüssigen Seherlebnis bei, während Schwankungen auf Stottern oder ungleichmäßige Frame-Pacing hinweisen.
  3. Integration von Flip Metering: Bei moderner Hardware und Technologien wie DLSS 4 wird die Frame-Pacing-Logik oft durch spezielle Hardware-Mechanismen wie Flip Metering unterstützt, die sicherstellen, dass die Frames gleichmäßig dargestellt werden. MsBetweenDisplayChange reflektiert diese Optimierungen direkt.

Einschränkung von MsBetweenDisplayChange: Diese Metrik allein gibt keinen direkten Einblick in die Effizienz der Render-Pipeline oder die Zeit, die eine Anwendung benötigt, um Frames zu produzieren. Sie ist primär auf die sichtbare Darstellung und Synchronisation ausgerichtet.

Technischer Vergleich der beiden Metriken

Aspekt MsBetweenPresents MsBetweenDisplayChange
Messpunkt Zeitpunkt der Übergabe eines neuen Frames an die GPU-Queue Zeitpunkt, an dem ein neuer Frame auf dem Display sichtbar wird
Fokus GPU-Queue und Anwendungsleistung Bildausgabe und wahrgenommene Fluidität
Relevanz für Nutzererfahrung Indirekt, da sie die Render-Pipeline betrifft Direkt, da sie die sichtbare Darstellung betrifft
Verwendung Analyse der Renderleistung und Pipeline-Engpässe Bewertung der Bildkonsistenz und -qualität
Bedeutung von Hardware-Optimierungen Weniger relevant Sehr relevant (z. B. durch Flip Metering)

Kommentar

Lade neue Kommentare

madmlink

Mitglied

24 Kommentare 18 Likes

Vielen Dank für die tolle Zusammenfassung von Grundlagen Know-How zu dem Thema. (y)
Ich empfinde es selbst immer als Herausforderung entsprechende Inhalte, oder das Verständnis, welches man sich selbst über Jahre angeeignet hat, anderen (meist jüngeren Menschen) kompakt zu vermitteln, um den kritischen Blickwinkel auf Messwerte & Daten zu schärfen.
Es wird mir eine Freude sein den Link zum Artikel als weitere Basislektüre an zukünftige Wissensdurstige weiterzugeben.

Antwort 2 Likes

Wombatlars

Neuling

5 Kommentare 0 Likes

Werden bei den Tests die 1% Low angegeben oder das P1? Ist ja nicht das gleiche. Siehe z. B. hier

Antwort Gefällt mir

E
Eribaeri

Veteran

155 Kommentare 61 Likes

Gut, dass das jetzt nochmal erklärt wurde!
Ich habe das Gefühl, dass das bald relevant werden könnte ;)
@Igor Wallossek wo liegen die 0.1% lows eigentlich in Prozent zu den FPS normalerweise? bei 50%? 60%? Also Bsp: 300fps, sind die .1% dann bei 150 in Ordnung?

Antwort Gefällt mir

Igor Wallossek

1

11,694 Kommentare 22,653 Likes

Der Zusammenhang zwischen dem P1-Low-Wert und einzelnen Frames sowie deren Renderzeiten liegt in der Art und Weise, wie die Bildwiederholrate und die Performance über einen bestimmten Zeitraum gemessen und ausgewertet werden. Einzelne Frames haben jeweils eine spezifische Renderzeit, also die Zeit, die benötigt wird, um einen Frame von der GPU zu berechnen und darzustellen. Generell rechne ich ja nur mit den Rohdaten, zu FPS wird das später erst.

Wenn man die Renderzeiten über einen längeren Zeitraum misst, entstehen Schwankungen. Diese Schwankungen spiegeln die variierende Last wider, die auf der GPU liegt. Insbesondere längere Renderzeiten führen zu spürbaren Einbrüchen in der Bildwiederholrate und können als Mikroruckler wahrgenommen werden.

Der P1-Low-Wert repräsentiert die Framerate, die an der Schwelle des unteren einprozentigen Bereichs der Messdaten liegt. Das bedeutet, dass die schlechtesten ein Prozent aller gemessenen Frames (bezogen auf die Renderzeit) in die Berechnung dieses Wertes einfließen. Anders gesagt, werden die langsamsten Renderzeiten, die ein Prozent der Gesamtframes entsprechen, zur Ermittlung des P1-Low-Werts herangezogen. Dies ist ein Indikator dafür, wie gravierend die Leistungseinbrüche in Extremsituationen sind.

Dadurch ist der P1 Low besonders sensitiv gegenüber kurzen, aber wahrnehmbaren Rucklern oder Leistungseinbrüchen, die durch lange Renderzeiten verursacht werden. Ein direkter Zusammenhang besteht also darin, dass der P1-Low-Wert stark von der Verteilung und den Extremen der Frame-Renderzeiten abhängt. Und genau deshalb mimmt man die Werte vorm Display und nicht nach der GPU :)

Antwort 1 Like

Klicke zum Ausklappem
8j0ern

Urgestein

3,399 Kommentare 1,073 Likes

Sehr interessant, danke Igor für den kleinen Einblick. ;)

Habe ich das richtig Verstanden: Scanout ist der Zeitpunkt wo das Bild am HDMI bzw. DP ausgegeben wird?

Ich habe mal CapFrameX beim Ingame Benchmark von Guardians of the Galaxy mitlaufen lassen.
Das ging in der Vergangenheit nicht sobald ich HDR10+ genutzt habe.

View image at the forums

View image at the forums

P1 = Gemittelte Frame Time
1% = Minimum Frame Time ?

Antwort Gefällt mir

Igor Wallossek

1

11,694 Kommentare 22,653 Likes

Perzentile der FPS (Hochgerechnet):

View image at the forums

Frame Time (Renderzeit der Frames) im Verhältnis zu den FPS:

View image at the forums

Ich arbeite intern generell nur mit den Rohdaten der Renderzeiten, FPS sind so ein grober, nichtssagender Wert, mit dem man echt nichts berechnen sollte.

Antwort 2 Likes

8j0ern

Urgestein

3,399 Kommentare 1,073 Likes

Ok, Danke.
Die 1% scheinen auch ein AVG Wert zu sein.
Die PX sind dann die Percentile von den FPS?

Schlimm genug, dass man es immer wieder erwähnen muss: Frame Times lügen nicht, FPS schon. ;)

View image at the forums

Antwort Gefällt mir

Annatasta(tur)

Veteran

425 Kommentare 171 Likes

Danke für die umfangreiche Aufklärung.

Antwort 1 Like

8j0ern

Urgestein

3,399 Kommentare 1,073 Likes

Jetzt nochmal mit Ultra Ray Tracing in Game:

View image at the forums

View image at the forums

Antwort Gefällt mir

Igor Wallossek

1

11,694 Kommentare 22,653 Likes

Die Werte von Marvel haben noch nie gestimmt. ist wie AC Mirage. Auch Fake :D

Antwort Gefällt mir

8j0ern

Urgestein

3,399 Kommentare 1,073 Likes

Irgendwie geht es immer, Fake gibt es leider über all.

Wenn es auf dem Display fluffig läuft, beschwert sich keiner wenn es nur 48Hz sind. :p

Antwort 1 Like

E
Eribaeri

Veteran

155 Kommentare 61 Likes

Danke für diese ausführliche Antwort, Igor! Mir war nur wichtig, zu wissen, ob bei einer Framerate von ~300fps .1% lows von 200fps gut sind, oder ob ich da noch was machen muss.

Antwort Gefällt mir

e
eastcoast_pete

Urgestein

2,207 Kommentare 1,407 Likes

Wie auch von @Igor Wallossek erklärt, legt (jetzt?) auch Nvidia viel Wert darauf, daß MsBetweenDisplay der bessere Messwert ist oder sein sollte. Gerade weil MsBetweenPresents beim Einsatz von Frame Insertion noch keine Aussage geben kann, wie gleichmäßig (flüssig) die Frames denn wirklich erscheinen. Wie @8j0ern geht's mir (wohl den meisten von uns) mehr darum, daß die Handlung auf dem Monitor flüssig aussieht als daß eine Karte mehr ausgelesene FPS hat als eine andere.
Sichtbare Mikroruckler waren deshalb (IMHO) einer der wichtigsten Gründe, warum SLI und Crossfire nie so breit eingesetzt wurden wie man nach den damit möglichen FPS Zuwächsen erwartet hätte. Es sah einfach nicht so rund aus wie erwartet.

Antwort 1 Like

NamaNatranius

Mitglied

65 Kommentare 25 Likes

Der FTI (Frame Time Interpreter) von igor’sLAB

Gibt es das tool von dir irengendwo auf der seite oder im forum zum download?

Hab nämlich genau sowas vor ein parr monaten im internet gesucht aber nicht gefunden was mich zufrieden gestellt hat. Hätte gern mal was wo ich meine empfidungen beim zocken wenns es sich nicht so flüssig anfühlt zu testen. Ich war mit capeframe nicht ganz zufrieden. Frameview hab ich halt nichts zum grafisch auswerten gefunden.

Antwort Gefällt mir

Igor Wallossek

1

11,694 Kommentare 22,653 Likes

Nein, gibt es nicht, weil da auch die ganzen Exportfunktionen für meine Charts und die Schnittstelle für die Scopemessungen drin sind. Das ist quasi Firmensoftwre :D

Aber vielleicht solle ich das Ganze wirklich mal auf den Interpreter eingrenzen und als abgespecktes Mini-Tool zum Frameview anbieten.

Antwort 1 Like

NamaNatranius

Mitglied

65 Kommentare 25 Likes

Wenn man die zeit findes wärd das ne echt schöne sache ich denk da würden sich auch parr andere leute darüber freuen.
Hab mir auch schon fast gedacht das nicht einfach so bereitstellen Kannst/möchtest.
Dachte fragen kostet nicht will mir ja die chance nicht nehemen was gutes bekommen.

Antwort Gefällt mir

RX480

Urgestein

1,943 Kommentare 926 Likes

Im NV-Treiber Flipmeter= ON sollte also helfen, das sich das Game nicht so ruckelig anfühlt ?
(weil spikes ca. 1/3 niedriger ausfallen, oder ist Das nur Zufall)

() = intelligente Outputsteuerung, um zw. Berg+Tal zu vermitteln

Das Game ist da wohl besonders auffällig?

Antwort 1 Like

RX480

Urgestein

1,943 Kommentare 926 Likes

Wem die Messungen zu kompliziert sind, kann bei AMD-Grakas auch einfach in den Advisor reinschauen.
Bsp. siehe Anhang

Antwort 1 Like

Igor Wallossek

1

11,694 Kommentare 22,653 Likes

Es hilft wirklich :)

Antwort 1 Like

Danke für die Spende



Du fandest, der Beitrag war interessant und möchtest uns unterstützen? Klasse!

Hier erfährst Du, wie: Hier spenden.

Hier kannst Du per PayPal spenden.

About the author

Igor Wallossek

Chefredakteur und Namensgeber von igor'sLAB als inhaltlichem Nachfolger von Tom's Hardware Deutschland, deren Lizenz im Juni 2019 zurückgegeben wurde, um den qualitativen Ansprüchen der Webinhalte und Herausforderungen der neuen Medien wie z.B. YouTube mit einem eigenen Kanal besser gerecht werden zu können.

Computer-Nerd seit 1983, Audio-Freak seit 1979 und seit über 50 Jahren so ziemlich offen für alles, was einen Stecker oder einen Akku hat.

Folge Igor auf:
YouTube   Facebook    Instagram Twitter

Werbung

Werbung