PresentMon: Measuring Frame Times and Latency in Windows Graphics Applications

What PresentMon measures that a frame counter does not

Average frames per second hides the thing that makes a game feel bad: individual frames that arrive late. PresentMon traces key performance metrics such as the CPU, GPU, and Display frame durations and latencies, according to the README. That is a different question from how many frames were drawn. A run that averages 60 frames per second can still contain a handful of frames that took three times as long as their neighbours, and those are the frames a player notices.

The audience is narrow and fairly technical. Graphics engineers and driver developers comparing behaviour across DirectX, OpenGL and Vulkan; engine programmers checking whether a frame-pacing change helped; and reviewers who want per-frame data instead of a summary number. The repository also notes that other programs build on this functionality, listing AMD OCAT, CapFrameX, Guru3D RTSS RivaTuner Statistics Server, Microsoft PIX on Windows System Monitor and NVIDIA FrameView. Those tools exist because the raw ETW analysis is useful but not pleasant to consume directly.

Three components, one ETW pipeline

The repository is split into directories that map to distinct products. PresentData/ holds the PresentMon Collection and Analysis library, described as performing the lowest-level collection and analysis of ETW events, with PresentData/PresentMonTraceConsumer.hpp given as the entry point for detail. PresentMon/ holds the console application that collects CSV data from target applications. IntelPresentMon/ holds two more things: the PresentMon Service, which combines the ETW frame event analysis with hardware telemetry such as GPU power, temperature, and utilization collected from vendor APIs such as NVAPI, and the PresentMon Capture Application, a GUI that talks to that service and can display an overlay with realtime graphs and readouts of any metric the service exposes.

So there are two data paths. The console application reads ETW events and writes CSV. The service also reads ETW events but merges them with hardware telemetry and exposes the result through the PresentMon API, which the capture application and any other client can consume. If you only need a CSV, the console path is the shorter one. If you want power and temperature alongside frame timing, the service is where those live, and it is the reason the project is not just a tracing tool.

Installing PresentMon and capturing a first trace

The README does not give a package-manager install. It states that binaries for the main releases are provided on intel.com or on the GitHub releases page, so the normal path is to download a release rather than build from source. Building is a separate concern; BUILDING.md covers building the components from source, and the repository root carries CMakeLists.txt, vcpkg.json, vcpkg-configuration.json, bootstrap.ps1 and requirements.txt, whose comment says the build orchestration currently uses only the Python standard library.

Before running anything, deal with permissions. PresentMon needs to be run by a user who is a member of the "Performance Log Users" user group. Without that, the README says you get an error reading "failed to start trace session (access denied)". The documented fix is to run compmgmt.msc as administrator, expand System Tools, expand Local Users and Groups, click Groups, double-click "Performance Log Users", click Add, type the account name, click OK, then sign out and back in for the change to take effect.

Once that is done, the console application is the fastest way to get data. The README-ConsoleApplication.md file is the reference for its options; the README itself does not reproduce the flag list, so treat the separate file as the source of truth rather than guessing at switches. The README does describe two behaviours worth knowing before you start: without administrator privilege, processes running on different user accounts or processes that are short-lived appear in the console and CSV as "<unknown>" and cannot be targeted by --process_name.

For the service and overlay path, the relevant references are README-Service.md and README-CaptureApplication.md. The README does not describe service installation steps, so read those files before assuming the GUI is a drop-in replacement for the console tool.

Where the numbers stop being trustworthy

Two documented limitations change how you read the output, and both are easy to miss.

The first concerns OpenGL and Vulkan. Applications that report a Runtime of "Other", which the README calls typical for OpenGL and Vulkan applications, have less instrumentation in the frame presentation process. The consequences are specific: CPUFramePacingStall always reports 0, and CPUFrameTime may be slightly less accurate. That inaccuracy propagates into latency calculations built on CPUFrameTime, namely GPUBeginLatency, GPUEndLatency and DisplayLatency. InputLatency is explicitly not affected. So a Vulkan title and a DirectX title captured on the same machine are not directly comparable on those columns, and a zero in CPUFramePacingStall for a Vulkan build means nothing was measured, not that nothing stalled.

The second concerns Hardware-Accelerated GPU Scheduling. When HWS is enabled, the README states that msUntilRenderStart, msUntilRenderComplete, msGPUActive and msGPUVideoActive may be later or larger than they should be. It gives a concrete example: in a GPU-bound scenario a frame's msGPUActive may be reported roughly 0.5ms larger than the true GPU work duration, with the exact amount depending on workload and GPU. The README also says an improved solution is WIP, which is a plain admission that the current behaviour is a known gap rather than a configuration mistake on your side. If your analysis depends on GPU-busy time, note whether HWS is on before you draw conclusions.

There is also a Windows 7 caveat: some users have reported system stability issues when forcibly shutting down PresentMon, and the README suggests using Ctrl+C in the PresentMon window instead. That is a narrow, dated case, but it is the documented shutdown procedure on that platform.

PresentMon against FrameView and CapFrameX

The README lists several programs that build on this functionality, which makes the build-versus-buy choice concrete. NVIDIA FrameView is a vendor tool tied to NVIDIA hardware; the README's description of the PresentMon Service mentions NVAPI as one of the vendor APIs used for telemetry, which tells you where the hardware data comes from and why a vendor-specific tool can present a tighter, GPU-branded experience. CapFrameX and AMD OCAT sit in the same space: capture and visualization on top of frame timing data.

The difference in approach is where the logic lives. PresentMon ships the ETW collection and analysis library separately from its front ends, and the service exposes metrics through the PresentMon API. A tool that consumes that API inherits the frame event analysis and adds its own presentation. That matters if you need to record your own metrics or drive a capture from a test harness, because you are not limited to what a vendor GUI decided to show. It matters less if you just want a graph on screen during a play session, where a finished application is less work. The MIT licence and the published API are the reason the ecosystem around PresentMon exists at all.

Licence, releases and what upgrades cost you

PresentMon is MIT licensed, with the notice reading Copyright (C) 2017-2024 Intel Corporation. The permission text is the standard MIT grant: use, copy, modify, merge, publish, distribute, sublicense and sell, provided the copyright and permission notice are included in all copies or substantial portions. There is no warranty. For a tool you embed in an internal test rig or redistribute with a product, that is about as permissive as it gets, but the notice requirement is real and the file is LICENSE.txt in the repository root. This is a description of the licence text, not legal advice.

The repository is not archived, and the last push was on 2026-09-25. Releases are frequent: v2.6.0 on 2026-09-21, and v2.5.0 and v2.5.1 both on 2026-06-29. That cadence is the upgrade cost. The console application writes CSV, and CSV columns are the kind of interface that quietly changes meaning between versions, so a capture pipeline that parses those files should pin a version and re-check the column set when moving. The service path adds a second surface, since clients talk to it through the PresentMon API. Nothing in the README describes a versioning or deprecation policy for either surface, so treat a release upgrade as something to validate against a known capture rather than assume is transparent.

Editorial conclusion

Use PresentMon if you are profiling frame pacing and latency on Windows and need per-frame CSV data rather than a single average frame rate. Do not use it as a general system monitor, and do not expect accurate GPU-active numbers on a machine with Hardware-Accelerated GPU Scheduling enabled, because the README states those measurements may be later or larger than the true GPU work duration. Before adopting it, verify three things: that your account is in the Performance Log Users group, which graphics API your target application uses, and whether HWS is on, since each changes what the captured numbers mean.

Frequently asked questions

Official sources

1. GameTechDev/PresentMon on GitHub
2. License: MIT
3. Project website
4. README
5. Releases