gametechdev / presentmon

Capture and analyze the high-level performance characteristics of graphics applications on Windows.

PresentMon

PresentMon is a set of tools to capture and analyze the high-level performance characteristics of graphics applications on Windows. PresentMon traces key performance metrics such as the CPU, GPU, and Display frame durations and latencies; and works across different graphics API such as DirectX, OpenGL, and Vulkan, different hardware configurations, and for both desktop and UWP applications.

This repository contains several components:

• The PresentData/ directory contains the PresentMon Collection and Analysis library: a library that performs the lowest-level collection and analysis of ETW events. See PresentData/PresentMonTraceConsumer.hpp for more information.

• The PresentMon/ directory contains the PresentMon Console Application: a standalone console application that can be used to collect CSV data from target applications. See README-ConsoleApplication.md for more information.

• The IntelPresentMon/ directory contains the PresentMon Service and PresentMon Capture Application: an easy-to-use GUI that can be used to collect and analyze target applications. See README-Service.md and README-CaptureApplication.md for more information.

There are also several other programs that build on this functionality and/or help visualize the resulting data. For example, see:

• AMD OCAT
• CapFrameX
• Guru3D RTSS RivaTuner Statistics Server
• Microsoft PIX on Windows System Monitor
• NVIDIA FrameView

Binaries for the main releases of PresentMon are provided on intel.com or github.com (list of all releases).

See CONTRIBUTING.md for information on how to request features, report issues, or contribute code changes.

See BUILDING.md for information on how to build PresentMon components from source.

License

Copyright (C) 2017-2024 Intel Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Troubleshooting

See GitHub Issues for a current list of reported issues.

User access denied

PresentMon needs to be run by a user who is a member of the "Performance Log Users" user group. If neither of these are true, you will get an error "failed to start trace session (access denied)".

To add a user to the "Performance Log Users" user group:

1. Run compmgmt.msc as administrator.
2. In the "Computer Management" window, expand "System Tools", expand "Local Users and Groups", and then click "Groups".
3. Double-click "Performance Log Users", and then click "Add".
4. In the "Enter the object names to select" text box, type the name of the user account or group account that you want to add, and then click "OK".
5. Sign out and log back in for the changes to take effect.

If PresentMon is not run with administrator privilege, it will not have complete process information for processes running on different user accounts or for processes that are short-lived. Such processes will be listed in the console and CSV as "<unknown>", and they cannot be targeted by name (--process_name).

Analyzing OpenGL and Vulkan applications

Applications that report Runtime of "Other" (e.g., as is typical with OpenGL or Vulkan applications) have less instrumentation in the frame presentation process. As a result, CPUFramePacingStall will always report 0 and CPUFrameTime may be slightly less accurate. This inaccuracy also impacts latency calculations based off of CPUFrameTime (e.g., GPUBeginLatency, GPUEndLatency, and DisplayLatency but not InputLatency).

Tracking GPU work with Hardware-Accelerated GPU Scheduling enabled

GPU execution metrics are less accurate when running on a system that uses Hardware-Accelerated GPU Scheduling (HWS). When HWS is enabled, msUntilRenderStart, msUntilRenderComplete, msGPUActive, and msGPUVideoActive measurements may be later/larger than they should be. For example, in a GPU-bound scenario the frame's msGPUActive may be reported ~0.5ms larger than the true GPU work duration, though the specific amount of the inaccuracy will be workload- and GPU-dependent.

An improved solution is WIP.

Shutting down PresentMon on Windows 7

Some users have observed system stability issues when forcibly shutting down PresentMon on Windows 7. If you are having similar issues, they can be avoided by using Ctrl+C in the PresentMon window to shut it down.

presentmon's Issues

Consume ETW metadata from within trace files

When a trace is collected and run through XPerf's -merge functionality (which is done for GPUView traces), there's additional synthetic events that are injected just before the first instance of each event that is parseable on the machine doing the merge, which contains all of the metadata necessary to decode the payload of these events.

Ideally, PresentMon should be able to consume these instead of going to TDH, in order to support capturing a trace on one system, and running PresentMon on it on another system, without having to worry about the event format changing between the two.

PresentMon crashes with Windows 19H1 Mixed Reality

Running on the latest Windows Insider builds, PresentMon crashes when running with mixed reality providers in a mixed reality scenario.

"Displayed fps" shows a much larger value

I use PresentMon 1.3.1 which customized to output the console display to a log file, built it on Win32 and used it.
While checking "displayed fps" with my own play player sometimes it may show a much higher value than the frame rate of the content. For example, it shows a value exceeding 200 fps with contents of 59.94 fps. And The display refresh rate is 59 Hz.
Under what conditions can "displayed fps" become a large value?

Name of NTProcessEventStructs.hpp is wrong in PresentData.vcxproj, causing project to always think it is out of date

The only consequence is visual studio constantly prompting you about the project being out of date. We just need to rename NTProcessEventEventStructs.hpp (notice Event twice) in the vcxproj file to NTProcessEventStructs.hpp.

Crash when using PresentMon64.exe

I'm using the latest build, and I'm getting an error when trying to use it with Hitman 47:

Assertion failed: !p->Completed, file PresentMonEtw.cpp, line 243

Test system has a GTX 980 Ti with 364.72 drivers. Not sure if that matters, but I'll look into it. Possibly Hitman is already monitoring things with the built-in benchmarking utility as well.

Nvidia CP frame limiter leads to high MsInPresentAPI values

A user on reddit compared different frame limiters, including NV CP and RTSS. CapFrameX provides input lag approximation based on your formular given in the GitHub description.

LatencyMs =~ MsBetweenPresents + MsUntilDisplayed - previous(MsInPresentAPI)

The problem is that the values for MsInPresentAPI are very high, so the overall latency becomes very low. This is only the case if the frame limiter from Nvidia is used. What's going wrong here? Is there a problem at all?

Capture data with NV CP frame limiter: https://pastebin.com/0ipbcaKs
Capture data with RTSS frame limiter: https://pastebin.com/ueSpNSWt

Memory Usage is too high

I am using a debug build built for x64 architecture OSes that was made with the latest source code. It is using between 60-70 MB of RAM when it should be using 20-30 MB of RAM.

No WMR events are generated

I'm interested in getting data about LSR and tried running PresentMon 1.5.2 with the -include_mixed_reality option.
My Windows version is 10.0.18363.752 and I'm running Mixed Reality Portal with the simulation headset since I don't have hardware at hand, but the output CSV file does not contain any data.

Is this a known issue, or am I doing something wrong?

Start benchmarking with a hotkey and stop after x seconds

First, i have to say thank you for PresentMon - it's really a great working tool!

What i miss a bit is the possibility to start benchmarking with a hot key and automatically stop after x amount of seconds.

The toggle key is working fine, but it's hard to stop after exactly the same time. Also the timed command is working fine, but it already starts with the opening of the tool - and so a bit too fast.

Vulkan capture seems broken in v1.2.0

I'm testing the Vulkan capture with the cube.exe from the LunarG Vulkan SDK, but PresentMon v1.2.0 doesn't seem to get any presents from it - v1.1.2 works fine. (Also the new ctrl+c behavior is a bit annoying, since you don't get back into the command line?)

Sample output from v1.1.2 in case that helps:

cube.exe,6312,0x0000000000000000,Other,-1,0,0,Composed: Copy with CPU GDI,0,3.329873,8.362,8.332,0.000,0.008,16.488

Console no longer (since 1.5) shows active swap chains / processes

Instead the console shows a detailed event log. I tried the command line options that probably should change this behavior, but there seems to be no way to get the pre-1.5 console output back.

Visualizer for PresentMon files

Hi, maybe the one or another is interested in a visualizer for Presentmons csv files, which I wrote:
https://github.com/PaulPiatek/presentmon-graph

[Win7] possible crash when PresentMon process being killed

file：PresentMon.cpp
line：868
Sleep(args.mDelay * 1000);
There is a delay time. When the PresentMon process is sleeping, kill this process would cause the operating system suspended. It looks like only the mouse cursor could move. The operating system does not respond to other operations.
How could I handle this situation？

Bad Vulkan data?

I've tried using PresentMon with two different Vulkan games, The Talos Principle and now Doom (which just got a Vulkan patch today). I didn't realize the problem on Talos, but it appears looking at the CSV files that PresentMon is capturing 'MsBetweenPresents' incorrectly or something -- or maybe Vulkan is just doing things wrong? Anyway, looking at the CSV files, all of the 'Hardware: Legacy Flip' frames have an interval that's a multiple of the display refresh time (e.g. 16.67 ms for 60 Hz).

If you manually subtract the previous row time from the current row time (column 'TimeInSeconds'), you get completely different numbers -- and some of the numbers are negative! So this method of determining frame times (and fps) is also borked.

In other words, right now with both publicly available Vulkan games, PresentMon is not providing useful data AFAICT. Thanks!

msvcp140d.dll missing - install 2015/2017 c++ runtimes doesn't help

Any clue?

repeated in several machines with W10 with latest 1703 update. Was working fine before

Output stream error

We are using the "output_stdout" option in CapFrameX to get the capture data from PresentMon. Now there is a user who has problems with CapFrameX. What we know from our logs is that CapFrameX does not get any data from PresentMon.

Is it possible that any global settings of Windows could be responsible for this? However, we only know of this one case. So it seems to be a very rare problem.

Frames captured with invalid MsBetweenDisplayChange value

Observed some frames with too-large MsBetweenDisplayChange value. Other values appear correct.

e.g.:

'DXGI', '0', '0', '1', 'Hardware Composed: Independent Flip', '0', '117.347658', '32.965', '6727011648977478.000', '0.643', '93.212', '93.212'

Terminating PresentMon results in unstable OS

When I terminate PresentMon while it is enabled on Windows 7, programs such as Pale Moon (http://www.palemoon.org) hang when I try to run them.

[Feature request] Runtime/API info

Some users would like CapFrameX to display the runtime. Could you please integrate this? What is currently included in the CSV files is the following:

Vulkan = Other
DX12 = DXGI
DX11 = DXGI
DX9 = ?
OpenGL = Other

The DirectX versions as well as Vulkan and OpenGL cannot be distinguished.

Redirect output

What can I do to redirect the console output of PresentMon within a C# application? I've tried

• ProcessStartInfo.RedirectStandardOutput = true + OutputDataReceived handler
• Nuget called ConsoleAppLauncher
• cmd command "PresentMon64-1.3.1.exe >> outputfile.txt 2>&1".

Nothing works...

crash when run two instances

Using "-process_id" to run two instances for two processes, then one of the PresentMon instance crash.

error: failed to query trace status (4201).
Assertion failed: EtwThreadsShouldQuit() || args.mEtlFileName, file PresentMon.cpp, line 99900000000

how to avoid this?

HSync flips should still be considered tearing

When an MMIOFlip's FlipEntryStatusAfterFlip is FlipWaitHSync, PresentMon will wait until an HSync DPC event comes in before considering the frame completed, which enables for more accurate timing than just assuming it completes immediately. However, an HSync is still a tearing Present, while PresentMon currently treats it the same as a VSync, which is non-tearing. We should track this metadata correctly.

Data collected on Win10RedStone2 (build 15034) with vsync off are not correct

Please implement the DxgKrnl_MMIOFlipMPO with immediate flip

Vulkan not recorded?

Hi

Been using PresentMon for quite some time now. It worked well, including for Vulkan.
For some reason, lately I have had problems with recording Vulkan frametimes and now it won't do it at all (work for anything else)

Could it be that some new NV or Windows 10 updates crapped something?
Could it be related to me using an external display with my laptop?

EDIT: I get the files, but they empty or have only the header line

Possibility for different processes with one batch?

Is it perhaps possible to implement a possibility to log different processes/games with one batch?
Right now it's only possible to log everything. This work with every game, but sometimes other processes are logged too.

And with the Process_name or the id command, it's only possible to log one game per batch file. if you want to log a few games, you need a lot of batch files...which is quite unhandy.

GetData on pSwapChain EventDataDesc in HandleD3D9Event can hit the size_>sizeof(T) assert

I'm not sure how widespread/easy this is to hit, but here is how I'm doing it. I verified the data being returned to _data is actually 8 bytes (the leading 4 bytes are non-zero).

1. Start hitman 2 running full screen by choosing "Play" at the launcher when starting it (you can get the base game for free on steam without any missions, and that is enough to hit the issue - it's at https://store.steampowered.com/app/863550/HITMAN_2/). Leave it at the menu where it says "PRESS [Enter] TO PLAY".
2. Once at the menu, alt-tab out of the game.
3. Start PresentMon.exe with:
   PresentMon.exe -process_name hitman2.exe
4. Alt-tab back into the game
5. Wait a few seconds
6. Alt-tab back out of the game.
   You'll get
   error: event's pSwapChain property had unexpected size (8>4)

where to find the etw event document?

for example, the event id:

enum {
        DXGIPresent_Start = 42,
        DXGIPresent_Stop,
        DXGIPresentMPO_Start = 55,
        DXGIPresentMPO_Stop = 56,
    };

and the event's user data struct:

    case DXGIPresent_Start:
    case DXGIPresentMPO_Start:
    {
        PresentEvent event;
        event.SwapChainAddress = eventInfo.GetPtr(L"pIDXGISwapChain");
        event.SyncInterval = eventInfo.GetData<uint32_t>(L"SyncInterval");
        event.PresentFlags = eventInfo.GetData<uint32_t>(L"Flags");
        event.Runtime = Runtime::DXGI;
        event.RuntimeThread = hdr.ThreadId;

the member name "pIDXGISwapChain", "SyncInterval", and etc.

i can't find the document.
can you tell me where i can find these info?
thanks.

Are Vulkan and OpenGL applications supported?

Improve PresentMode documentation/naming

Add description of PresentMode to readme (e.g., this answer: CXWorld/CapFrameX#114 (comment))

Also consider renaming PresentMode text to be more inline with API, MSDN, etc. Note that this could be a breaking change as various tools do rely on current naming. (e.g., to do for 2.0 major version release)

Option to output datetime of present, instead of TimeInSeconds since capture start

Is it possible to write each data line (frametime) together with timestamps? I could really use it to compensate variations of the recording time interval.

Maybe you can provide an option to switch it on/off.

[Q] Evaluation of the quality of adaptive sync technologies

How can we use the data from PresentMon to evaluate adaptive sync technologies? MsBetweenDisplayChange values are apparently unsuitable for this. The graphs show an adaptive course when V-Sync and G-Sync are disabled. MsUntilDisplayed is quite high. How can this be? The values are partly over 40ms, although I have a 120Hz monitor and partly over 200 FPS depending on the game.

Thanks, Mark

Presents to child windows don't get tracked properly.

When a "copy with GPU GDI" present (at least) is done against a child window, the events from D3D/DxgKrnl indicate the child window handles, while the events from DWM indicate the top-level window handles. This causes frames to get stuck waiting for DWM to acknowledge them.

SwapChainData occasionally cleared too early

The constant is declared as
CHAIN_TIMEOUT_THRESHOLD_TICKS = 10000, // 10 sec
but is then used exclusively to compare against QPC differences. This means the timeout varies depending on machine, since QueryPerformanceFrequency values vary, and is significantly less than 10 seconds. This means PresentMon will give up on a chainmap after something as small as a 1 second hiccup in a game's graphics output.

(from OCAT) Ability to Generate Separate CSV files for Applications

Like the blacklist request, this is another feature OCAT previously had but lost to help keep up with PresentMon updates. It previously would generate individual CSV files for every application it recorded, and name each file accordingly.
The OCAT issue for reference: (v1.1.0.60) Single csv made when recording All Processes

Improve realtime performance with better filtering.

When calling EnableTraceEx2 with the ENABLE_PROVIDER control code, we have the opportunity to pass an ENABLE_TRACE_PARAMETERS struct. We should do so, and include the EVENT_ENABLE_PROPERTY_IGNORE_KEYWORD_0 flag, along with a filter.

We can provide an EVENT_FILTER_DESCRIPTOR entry with type EVENT_FILTER_TYPE_EVENT_ID. The EVENT_FILTER_EVENT_ID struct that we pass should be filled out with FilterIn set to TRUE, indicating that the events are to be included and not excluded, and the array filled with events that PresentMon knows how to handle.

The Handler struct will need to be extended to include the set of known event IDs, and the AddProvider method will need to be extended as well.

(from OCAT) Blacklist of Applications

I've been using OCAT for capturing frame time data, and while it previously had the ability to blacklist applications from being recorded, this feature was removed to ease keeping up with PresentMon. As explained on the OCAT page, the easiest way to see this return to OCAT would be for PresentMon to gain the feature directly. I hope that might be possible, but I've got an R script to remove unwanted entries, so at least I have a workaround.
Here's a link to the OCAT issue: (v1.1.0.60) Blacklist seems to be ignored.

Thoughts on getting new QPCTime in seconds instead of counter units?

Wanted to see what y'all thought of this; definitely can close if not desired.

@DevTechProfile wanted some stuff to be able to synchronize with PresentMon data, and the QPCTime you added lets him do that. I had a similar need a while back, so I had forked to customize and was recording the QPC time, but in seconds. That is, QPC/QPF. Some other software, as well as some stuff I've written, records time in this way. Plus then you get values in a unit that is a bit more intuitive.

Any reason to prefer the raw QPC values over converting them to seconds? If everyone preferred it, I could use the feature as well. If not, I can just maintain in my fork.

ETW Packets Lost

Hello, I keep getting the Error: Some ETW packets were lost. Collected data is unreliable.

What could be the cause of this issue?

Request: separate files for each scroll-lock toggle

Right now, all data appears to get captured into a single monolithic file. That's great for some, but if you want to test different settings/areas, it doesn't really work well. I'm not looking to get into coding, but can I request someone add a feature to create a new file each time scroll-lock is activated? Ideally, PresentMon shouldn't start writing to any file until it's actively counting frames, at least if the -scroll_toggle option is passed to it. Then it would be easier to open a new file, start writing data, and stop when finished.

Thanks for reading; I have no idea if anyone will pay attention. You can email me if you want to talk about this (look up Jarred Walton on PC Gamer if you need an address).

How to read the .csv files

This is not an issue exactly, but I couldn't pull a request.

I have recorded and logged some action, but I don't find the FPS numbers.
Could you give some instructsions on how to obtain those out of the .csv file?

Include etw_list tool?

run_etw_list.cmd seems to reference etw_list tool but it's not clear where to get it from.

PresentMon 64 closes on launch

when launch the cmd windows comes up and goes away does this every time i tried to use it already run it as admin and disable antivirus

Wrong frametimes for Deus Ex: Mankind Divided in DX12 mode

I'm running a lot of PC games benchmarks for quite a while using PresentMon to collect frametimes and so far Deus Ex: Mankind Divided in DX12 mode is the only game I have issues with. Below are two frametime graphs made from PresentMon output files after running the game integrated benchmark - the first one for DX11 mode and the second one for DX12 mode (output files themselves are inside the archive enclosed as well). Frametimes in DX11 mode look perfectly fine, but numbers in DX12 mode are quite odd. The benchmark itself starts at about 80 s, but even prior to it DX12 frametime values are very strange.


Deus Ex Mankind Divided.zip

Input lag parameter

I'v got just a question. I hope it's ok. What parameter/column header represents the input lag (the delay between pressing a button and seeing the game react)?

Stability issues on Windows 7 with low-RAM systems.

We've been having issues in our tests, mostly with systems with 4 GB of RAM and less lately.

Support for Windows 7 is now much better than it was and works with and without the -simple command and binds to processes properly. However, only on Windows 7 (we haven't had issues on Windows 8.1 and Windows 10) we encounter very important system slow downs or hard-locks (requiring a reboot) after PresentMon has logged for a while.

We usually log for about 5-10 minutes at a time, single process in a csv on the desktop. It hasn't been an issue before as far as I remember and generally does not seem to appear with FRAPs. Looking at system usage doesn't seem to show any abnormal or disproportionately large CPU/Memory usage.

We've gone through our tools one by one and PresentMon definitely seems to be causing these issues. It does not seem to occur on all systems and we are sometimes able to do 4-5 x 5 minute logs before we run into the issue.

Is there any sort of logs I could provide on one of the affected system? Naturally, I'm not sure if this would be possible due to the fact that the whole system will usually lock-up, even after closing all tools.

Help would be greatly appreciated as this has been affecting our work for a while now! (And resulted in quite a few false positives unfortunately...)

Thank you!

Windows 10 Creators Update

Something seems to have changed quite a bit with Creators Update. PresentMon no longer collects any useful data from Doom Vulkan as an example, which was one of the few games where I needed it to work. The Hotkey option also doesn't seem to work at times (I tried it with Doom and didn't even get a results file for some reason).

Compatibility with Windows 7, 8.1 and 32-bit operating systems.

I work doing performance analysis of D3D applications and one of the most valuable information is the frame time/frame rate. We have been using FRAPs for years now and I have been looking into substituting it with PresentMon completely. My only issue right now is that the application is 64-bit only and does not appear to record data on Windows 7 and 8.1.

Is support for these operating systems (and 32-bit OSes) planned at all? It would be extremely helpful for us it it were.

Thank you!

Feature Request: FPS counter on the APP screen

You are about to read some bad English. and I am really sorry about it. I am not a native English speaker.
Hey developer thanx for creating this FPS monitoring tool for UWP
but for me actually it is not really that useful because I want too see FPS in realtime but your
PresentMon doesn't give me that functionality and I am fully sure that 90% of users want too see the fps in realtime not on back of the screen Can you plz do something about it
Can you plz add a FPS Counter on the right bottom of the screen

[Q] Input lag approximation

We've implemented the input lag approximation. Example and download link here: https://twitter.com/CapFrameX/status/1216398182734794753

I have some questions about this. After some testing serveral games, the values seem somewhat low to us. What could be the reason for this? Can the "MsUntilDisplayed" values really be read out correctly? I thought that is not possible until now.

"-hotkey" switch results in high CPU overhead

The hotkey implementation is currently broken. When the program is used with "-hotkey" switch the program fully consumes a single CPU core, resulting a vast CPU overhead in CPU limited scenarios.

The issue is present during both the wait period (prior pressing the hotkey, F11) and during the actual data acquisition (after the hotkey has been pressed). The issue can be easily replicated even without running any 3D application: "PresentMon64 -process_name anyname.exe -hotkey". The program will immediately fully consume a single CPU core. To verify it on a multicore CPU, you can set the process affinity to a single core (to see the 100% utilization).