New features
- Support Intel Arrow Lake
- PresentMon v2.2 with new Start-to-PresentReturn / PresentReturn-to-PresentReturn frame time measurement approach
- New CPU Busy metric which indicates the duration the CPU was engaged in processing the frame before presenting it
Image source: VideoCardz
Enhancements
- PMD metrics as floating point numbers with one decimal digit
Bugfixes
- Exception handling AMD ADLX API calls
Info
With the new PresentMon version the frame time measurement approach has changed from Present-to-Present to Start-to-PresentReturn / PresentReturn-to-PresentReturn. Taken from the PresentMon release notes:
"The majority of metrics are changed to use the time that the CPU started working on a frame as the reference point instead of the present() call, with values that are more aligned to measuring the quality of graphics applications (e.g., latency and duration of interaction and displayed frames). See README-ConsoleApplication.md for more details."
Unwinder (the author of RTSS):
"There is no best or preferable method. Both have their own different usage cases. Frame-start-to-frame-start frametime graph can be used to validate framepacing quality of latency oriented framerate limiting modes (low latency SK limiter mode, async/back edge sync RTSS limiter modes, NV CPL framerate limiter etc). Such graph should become "flat" when such framerate limiting strategy is in use. Present-to-present frametime graph can be used to validate framepacing quality of framerate limiters prioritizing presentation timings adjustment (latent sync or normal framerate limiter in SK, front edge sync or scanline sync in RTSS). Such graph is expected to jitter if latency oriented framerate limiting strategy is in use, but become "flat" if framerate limiter prioritize presentation timings adjustment. You may also switch between these two modes to determine which framerate limiting strategy is used by some other third party framerate limiters or in-game framerate limiters."
