AlexUnwinder

Thanks! I peeked inside GpuTrace.cpp and see a change labeled "Add support for out-of-order monitored fence completion", which was committed after 1.9.2. Probably that's the reason.

To verify that I tried to rebuild console 1.9.2 with the latest versions of GpuTrace.cpp/h and confirmed that it introduced the problem too.

Sure, why not. Official home product page for RTSS is https://www.guru3d.com/files-details/rtss-rivatuner-statistics-server-download.html (please take a note that the build with new PresentMon SDK integration is not publicly released there yet).

RTSS 7.3.5 beta 3 build 27699 with PresentMon integration is released, download link is available in this post: https://forums.guru3d.com/threads/msi-ab-rtss-development-news-thread.412822/page-207 Fastest way preview it is to load one of two built-in...

And an example of using it to display realtime CPU/GPU bottleneck indicator in overlay: https://www.youtube.com/watch?v=4dmxoqqElY4

> In this example I see present mode change from composed-flip to hw-independent-flip at about 14s, but a decreased frametime isn't displayed until around 30s. Is the data lag getting...

You may reconstruct V1 metrics from V2 ones: CPUWait = msInPresentAPI CPUStart is the frame start timestamp, which matches with return from present() call, so you can calculate present() call...

Cannot say about all tools which will integrate PresentMon 2.0, but at least for RTSS PresentMon metrics integration I'll provide new V2 metrics together with reconstructed V1 metrics, so users...

Excellent, thanks! That's exactly what I was hoping to hear. It won't be a problem to update the clients a few times while the service is travelling to v1.0.

That's because CPUBusy is not what you think it is. That's just a frametime minus time spent inside Present() call. They are expected to be close to frametime unless Present()...