GameTechDev
PresentMon Beta overlay lags 3 seconds behind what's happening
Maybe the title isn't very clear, sorry. What I mean is that the values and, thus, graphs shown in PresentMon Beta are always 3 seconds behind. For example, a game has two scenes: The first can be rendered at 60FPS, and the seconds at 45FPS. The first scene is being rendered, PresentMon Beta will show 60FPS, but then the second scene is shown. The framerate will drop to 45FPS, but I'll have to wait 3 full seconds to be able to see this 45FPS value in PresentMon Beta, even when using the "Raw" values
I had to apply similar display lag to PresentMon's frametimes displayed in RTSS overlay to allow smooth scrolling and hide effect of batched frametimes streaming. Not sure if it is avoidable. A bit more info on the nature of delay here:
https://forums.guru3d.com/threads/msi-ab-rtss-development-news-thread.412822/page-206#post-6163230
Hi, thank you for your interest in Intel PresentMon. The delay you mention is known and is by design. The underlying issue is that the information we use to generate metrics is derived from ETW (Event Tracing for Windows) events, which come in with a delay, and further can only be polled at most once per second. As alluded to by @AlexUnwinder, in order to hide the effect of 1000+ ms worth of frame data suddenly appearing, the data is further delayed to allow for smooth scrolling of the data.
In the future, we may consider adding a mode where raw data "spawns in" instantly as it is available. This would reduce latency by as much as 1 second. Also, we are considering adding the option of an overlay via hooking/injection instead of MPO (Multiplane Overlay). If we implement this, we may also implement for zero delay graphing of frametime/FPS only, since we could measure these values directly via the target application's Present calls.
Note that the above are merely possible improvements we may undertake in the future, but as of today nothing is planned.
Removing the 'wontfix' label as I may look at this at some point. The ~1 second delay is just the default, it may be possible to reduce the buffering to get a lower-latency without losing critical events.
Also, we are considering adding the option of an overlay via hooking/injection instead of MPO (Multiplane Overlay).
This is urgently needed since at least 16% of Steam users don't own MPO capable GPUs, and that's just counting the NVIDIA GPUs I know don't have MPO capabilities. The real number is probably much higher.
Why is it urgently needed?
Not having MPO hardware shouldn't prevent the overlay, it will just have more of a performance cost during compositing. And even still this should be less of a cost than hooking every present, as the overlay can render less frequently than the game.
Doesn't the lack of MPOs in this case result in Composed: Flip instead of Hardware Composed: Independent Flip, leading to higher latency due to forced buffering?
Also, we are considering adding the option of an overlay via hooking/injection instead of MPO (Multiplane Overlay).
This is urgently needed since at least 16% of Steam users don't own MPO capable GPUs, and that's just counting the NVIDIA GPUs I know don't have MPO capabilities. The real number is probably much higher.
But there will be much more cons than pros in case of going this way. Hooking/injection based implementation is way more complex from development point of view, it requires separate renderer implementations for D3D8, D3D9, D3D10, D3D11, OGL and VK, it has much higher chances to conflict with games or other overlays/videocapture/streaming apps due to hooking/injection, it has higher chances to stop working in some games due to anticheat and it will surely stop working in some games where injection is not allowed globally and current implementation works (e.g. Destiny 2, CSGO or FIFA 23). So it is a jar of worms case.
Yep there are tradeoffs either way.
I mainly wanted to make sure I understand your priority: sounds like the concern is around performance impact, including potentially unfairness of different performance impact on different GPUs. That makes sense and we'll try to improve this. Short term you can put the overlay into windowed mode and move it to another screen if you have one.
Also, we are considering adding the option of an overlay via hooking/injection instead of MPO (Multiplane Overlay).
That'd be amazing, I'd love to capture an ingame video with the overlay, but I don't do that at the moment because it puts a game into Composed: Flip and we I don't like that.
Thanks for your work, amazing stuff!
VRR is not possible in the composition mode that PresentMon's overlay requires unless MPOs are supported. So, yes there's some general performance loss from composition, but there's also a fundamental change in the way presentation is displayed on screen, invalidating the point of PresentMon.
Moving the overlay offscreen works, but I think consumers need to be more educated on this. MPOs are very nebulous to most users, they aren't going to know that having this overlay on screen is giving them a presentation mode that they wouldn't have without it.
It's not urgent to implement a direct hook rendering system, but it is important to make sure users better understand when presentation model has been altered.
For context,
We use a simplified fork of PresentMon in our overlay in order to get the presentation model -- it's literally the only data we're interested in that PresentMon provides. This is your biggest contribution to this space, there are no APIs to check presentation model. Please don't undersell the importance of reporting presentation model without changing presentation model :)
