Basics GPUs Practice Reviews

A look into the lab: Correctly recording render time, time between actual image changes and variances in benchmarks

In order to precisely measure the performance of graphics cards, the use of specialized benchmarking software is essential. These programs log demanding graphics processes in order to test the capabilities of the GPU under realistic conditions. Some of the best known tools are based on PresentMon, a low-level tool developed by Intel to capture frame presentation times and other graphics performance data. PresentMon enables the monitoring of presentation events generated by graphics APIs such as DirectX, OpenGL and Vulkan. It captures important metrics such as frame rates, frame times and latencies that are critical for analyzing graphics performance. Several advanced benchmarking programs have been developed based on PresentMon, offering a more user-friendly interface and additional features.

Many of the leading graphics card performance measurement tools are based on PresentMon, a low-level diagnostic tool developed by Intel to capture precise information about frame presentations and their timing. NVIDIA FrameView is one of these programs that uses PresentMon as a foundation, but is optimized specifically for GeForce GPUs and offers additional features such as GPU-specific data integration, visual representations and optimizations to increase measurement accuracy. Another tool, CapFrameX, stands out with a user-friendly interface that enables detailed analysis and comparison of frame times and is also based on PresentMon. OCAT (Open Capture and Analytics Tool), an open source project, also uses PresentMon and is aimed at developers and testers who want to carry out comprehensive analyses of graphics performance across various APIs. In addition, there are specialized tools such as PresentMonLauncher, which makes PresentMon easier to use with a simpler interface and more accessible, especially for beginners. Each of these tools aims to evaluate the capabilities of GPUs by accurately capturing and analyzing frame data, providing an indispensable foundation for benchmarking and optimization in the world of computer graphics. Well, and then came Blackwell and DLSS4…

How PresentMon works

PresentMon monitors the presentation events generated by DirectX, Vulkan and OpenGL-based applications. Each time a frame is passed from the application to the GPU or rendered by the display manager, PresentMon captures the relevant events. The data captured includes, but is not limited to:

  • Presentation times: When a frame was passed to the GPU queue.
  • Frame latency: The time between the transfer of a frame and its actual display.
  • Frame pacing: Uniformity of the presentation of frames to identify stuttering or inconsistencies.
  • API-specific data: Capture of presentations triggered via DirectX 9, 11, 12, Vulkan or OpenGL.

The logs generated by PresentMon can be processed for analysis with external tools. It is particularly useful for debugging and optimizing applications as it provides a precise and detailed view of the frame rendering process.

PresentMon as the basis for NVIDIA’s FrameView

NVIDIA has used PresentMon as the technology foundation for its own FrameView tool to analyze the performance of GeForce GPUs and compatible applications. While PresentMon is designed as a generic low-level diagnostic tool, FrameView extends its functions with a simple interface and additional optimizations specifically tailored to NVIDIA GPUs. But of course FrameView also works with Intel and AMD graphics cards.

FrameView enhancements compared to PresentMon:

  1. Integration of GPU-specific data: FrameView combines the frame data collected by PresentMon with hardware-specific information from NVIDIA GPUs, e.g. GPU utilization, energy consumption and temperature.
  2. Improved visualization: Unlike PresentMon, which only provides log data, FrameView provides a graphical user interface to display real-time performance metrics.
  3. Optimizations for accuracy: NVIDIA has fixed and optimized known weaknesses in PresentMon, such as the handling of certain edge cases when measuring MsBetweenDisplayChange, to deliver more accurate results.
  4. Extended compatibility: FrameView supports additional features such as the analysis of DLSS-based frame generations and hardware-accelerated technologies such as flip metering, which is not directly implemented in PresentMon.

Using PresentMon as a base allows FrameView to rely on a proven and robust framework that is compatible with various APIs and platforms. However, NVIDIA has adapted FrameView so that it can be used specifically for the analysis of GPU-specific technologies and optimizations, especially in the context of DLSS and frame generation algorithms. This also applies to DLSS4 and the correct acquisition of render and display data. PresentMon and FrameView can be seen as complementary tools: PresentMon provides a universal and detailed foundation, while FrameView extends this with user-friendly features and NVIDIA-specific optimizations to provide developers and testers with a more comprehensive analysis platform.

The FTI (Frame Time Interpreter) from igor’sLAB

And yet this still doesn’t generate chart graphics. This is precisely why I have programmed quite flexible software for internal use, which has been able to evaluate the log files from FrameView correctly and appropriately for all my charts for years. Today I would like to explain and justify why an important distinction needs to be made here. While most tools such as CapFrameX still use the MsBetweenPresents metric, you simply have to move with the times. Because PresentMon offers much more in the log files than just the pure render time of the GPU. I use two metrics here for good reason and I can only hope that all the tools will also follow suit with the introduction of NVIDIA’s MFG at the latest, because a lot of things weren’t quite correct even today. The picture below shows my in-house software, which then dutifully fills my Excel charts card by card (which I’ll show you in a moment):

The metrics MsBetweenPresents and MsBetweenDisplayChange are two important metrics in the area of graphics processing unit (GPU) performance evaluation and play a central role in analyzing image output processes and their impact on the user experience. To explain the difference between these two metrics in detail, it is necessary to look at the entire frame generation and display process, from the processing of a frame by the GPU to the actual display on the screen.

MsBetweenPresents: Time between two frame presentations

The MsBetweenPresents metric measures the time between two consecutive presentations of a frame by the GPU. This occurs when the GPU receives a new image for processing and transfers it to the render queue. The metric is an indicator of the frequency with which the application creates frames and provides them to the GPU. These are the values I use to evaluate the average FPS. Let’s take a look at this mode in my software and note the results:

MsBetweenPresents features:

  1. Focus on GPU queue: the metric measures the time at which a new frame is passed for processing, regardless of when it is actually displayed.
  2. Application performance: MsBetweenPresents reflects the efficiency of the render pipeline and how quickly the application is able to produce and pass frames to the GPU.
  3. Suitability for CPU/GPU analysis: This metric is particularly useful for identifying bottlenecks caused by the application or the GPU queue. For example, if the application is delivering frames too slowly, MsBetweenPresents will increase even if the GPU is performing well.

Limitation of MsBetweenPresents: MsBetweenPresents does not take into account when a frame actually becomes visible on the screen. This means that this metric does not provide any information about the synchronization with the display or the perceived fluidity by the user. It is therefore more focused on analyzing the render pipeline.

MsBetweenDisplayChange: Time between actual image changes

The MsBetweenDisplayChange metric captures the time between two visible changes of the displayed image content on the screen. This is the moment when the display actually outputs a new image that has been finalized by the GPU. I use this value for the variances and the P1 Low (including my percentile curves) because it accurately reflects the display. Again, to illustrate the display in the interpreter and you can see very clearly that the output image appears “rounder”, i.e. smoother than the previous curve of the usual programs actually implied.

Features of MsBetweenDisplayChange:

  1. Focus on the display output: this metric not only includes the render time, but also takes into account the entire process up to the display on the screen. This also includes synchronization with the refresh rate of the monitor.
  2. Importance for the user experience: It is particularly relevant for the evaluation of perceived fluidity and image consistency. A low and consistent MsBetweenDisplayChange time contributes to a smooth viewing experience, while fluctuations indicate stuttering or uneven frame pacing.
  3. Integration of flip metering: With modern hardware and technologies such as DLSS 4, the frame pacing logic is often supported by special hardware mechanisms such as flip metering, which ensure that the frames are displayed evenly. MsBetweenDisplayChange directly reflects these optimizations.

Limitation of MsBetweenDisplayChange: This metric alone does not provide direct insight into the efficiency of the render pipeline or the time it takes an application to produce frames. It is primarily focused on the visible display and synchronization.

Technical comparison of the two metrics

Aspect MsBetweenPresents MsBetweenDisplayChange
Measuring point Time at which a new frame is transferred to the GPU queue Time at which a new frame becomes visible on the display
Focus GPU queue and application performance Image output and perceived fluidity
Relevance for user experience Indirectly, as it affects the render pipeline Direct, as it affects the visible display
Usage Analysis of render performance and pipeline bottlenecks Evaluation of image consistency and quality
Importance of hardware optimizations Less relevant Very relevant (e.g. through 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,672 Kommentare 22,608 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,398 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,672 Kommentare 22,608 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,398 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,398 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,672 Kommentare 22,608 Likes

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

Antwort Gefällt mir

8j0ern

Urgestein

3,398 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,201 Kommentare 1,405 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,672 Kommentare 22,608 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,938 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,938 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,672 Kommentare 22,608 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

Editor-in-chief and name-giver of igor'sLAB as the content successor of Tom's Hardware Germany, whose license was returned in June 2019 in order to better meet the qualitative demands of web content and challenges of new media such as YouTube with its own channel.

Computer nerd since 1983, audio freak since 1979 and pretty much open to anything with a plug or battery for over 50 years.

Follow Igor:
YouTube Facebook Instagram Twitter

Werbung

Werbung