GameTechDev
MsBetweenPresent time 0 with XeSS FG
Generated frames are being logged with MsBetweenPresent time = 0 (PM v2.3.0). Tested with latest XeSS FG implementation in Marvel Rivals.
"MsBetweenPresents": [
19.4536,
0.0,
19.5659,
0.0,
21.2128,
0.0,
20.8951,
0.0,
20.3091,
0.0,
19.1364,
0.0,
19.233,
0.0,
18.9373,
0.0,
21.3202,
...
Most critical problem is that CPUStartQPCTime is equal to the previous frame. See normalized data as follows.
"TimeInSeconds": [
0.0,
0.0,
0.0195659,
0.0195659,
0.0407787,
0.0407787,
0.0616738,
0.0616738,
0.0819829,
0.0819829,
0.1011193,
0.1011193,
0.1203523,
0.1203523,
0.1392896,
0.1392896,
0.1606098,
0.1606098,
0.17934540000000002,
0.17934540000000002,
0.20224970000000003,
0.20224970000000003,
0.22074700000000003,
0.22074700000000003,
0.24468810000000002,
0.24468810000000002,
...
Hello,
Thanks for reaching out! To clarify, is your question regarding the 2.3 console application? Additionally, when CPUStartQPC matches the previous frame, do you observe the FrameType alternating between "Application" and "Intel-XeSS-FG"? If so, this behavior is expected. Let’s go over what PresentMon is doing.
Understanding PresentMon’s Behavior PresentMon tracks the workload associated with native application frames. It uses CPUStartQPC to mark when the application begins processing a frame and relies on the frame’s Present() call to determine CPU Busy, CPU Wait, and the overall FrameTime. This method works well for native frames, but interpreting these metrics for generated frames is different.
When PresentMon detects the frame type using the Intel Provider events, it aligns CPUStartQPC with the corresponding native frame and sets CPU Busy, CPU Wait, and FrameTime to zero, since these values are not meaningful for generated frames.
Currently, PresentMon can only detect generated frames for Intel-XeSS-FG and AMD-FMF (see note below).
Addressing Issues with Frame Type Reporting If PresentMon’s approach to distinguishing native animation work is causing issues, here are two potential solutions:
Disable Frame Type Tracking: You can omit the --track_frame_type argument. This prevents PresentMon from tracking frame types, meaning Intel-XeSS-FG frames will be reported similarly to DLSS and FSR-generated frames.
Modify Frame Time Calculation: Instead of using the generated frame time calculation, you could check the frame type and handle it differently. This approach provides a more apples-to-apples comparison across all frame generation techniques, ensuring that every Present() call is counted consistently.
Ongoing Discussions We are currently working with other vendors to better align on the FrameTime metric and hope to reach a consensus soon.
Note: AMD-FMF currently has a bug and is not reporting the frame type.
Additional Question We also have a quick question—It looks like you are using version 2 of the metrics and then converting them back to version 1. Can you confirm if this is correct?
Looking forward to your response!
Yes, it's v2.3 console application.
The question is, why do AMD and Nvidia at least track the render time of the generated frame, so that MsBetweenPresent isn't 0. My point is that MsBetweenPresent=0 leads to internal issues when calculating metrics in CapFrameX.