Periodic Zeros on Graphed Frame Metrics

[planetchili]

It has been reported on at least one machine that frame metrics after IPC/calc/middleware rework periodically and briefly dip to zero. Was demonstrated with Heaven benchmark. Seems to correlate with scene transitions.

[planetchili]

Attempted repro on following machines with Heaven.exe:
Mobile Win11 ThinkPad iGfx 10th Gen i7
Mobile Win10 Lenovo iGfx 10th Gen i5
Mobile Win10 Predator RTX 2060 10th Gen i7
Desktop Win10 RTX 2080 Ti Ryzen 7 5800X
Desktop Win11 Arc 750 11th Gen i9

No repro was possible.

[planetchili]

Currently no known common factor in the environments that produce this effect. Mobile or otherwise CPU-bound platforms were considered, but we have instances of low performance machines that do not exhibit. Battlemage has also been considered as a factor, but again BMG machines have been shown to function fine. The only common factor so far is that the known machines (Mobile w/ Intel iGfx and NUC with BMG(?) are both Intel graphics/system.

[planetchili]

Tests with extensive logging on one problem machine has shown that the problem exists in latency of frame data being output from the service. This basically rules out IPC / Calculation / Swap Tracking / Middleware stats as the problem. Assumption was that ETW event delivery was being delayed. However, after adding more fine grained logging on latency statistics which differentiate ETW latency from frame processing latency, we find that ETW is delivering on time, but frames are getting release very late relative to their present timestamp.

[@Debug] <service(6196):35628> {2026-03-05 16:45:48.1651653 PST}
  ETW event latency stats [87715 events] avg=11.179 ms min=7.019 ms p01=7.370 ms p05=7.755 ms p10=8.182 ms p50=11.109 ms p90=13.883 ms p95=14.572 ms p99=17.305 ms max=20.821 ms
  >> at PMTraceSession::ProcessEtwEventLatencyStats 
     C:\Files\Repos\PresentMon\PresentData\PresentMonTraceSession.cpp(752)
[@Debug] <service(6196):24040> {2026-03-05 16:45:48.7424481 PST}
  ETW frame latency stats [2561 frames] avg=327.712 ms min=25.741 ms p01=44.069 ms p05=78.862 ms p10=108.081 ms p50=321.199 ms p90=533.955 ms p95=559.620 ms p99=590.096 ms max=9640.002 ms
  >> at RealtimePresentMonSession::FlushFrameLatencyStatsWindow_ 
     C:\Files\Repos\PresentMon\IntelPresentMon\PresentMonService\RealtimePresentMonSession.cpp(395)

Delays of 2000-3000 ms happened multiple times over a small 2 minute session, and as seen above 10000ms delays are also possible it seems.

For the current release we will reinstate the last-known-good zero-filling mechanism as it at least does no harm relative to prior releases. Possible future work:

• Investigate this frame processing latency. Determine if it is causes by flaws in the ETW frame tracking state machine logic, by drivers etc. reporting essential events late/not at all, or some other cause.
• Implement an API mechanism for surfacing instances of stats window integrity violation + IPM capability which taps into this information and corrects already-graphed poll points.
• Implement adaptive auto-offset to select best tradeoff between dynamic query latency and data integrity (would likely not help this specific situation, but will improve behavior on systems with fewer resources).