AlexUnwinder
commented
1 month ago 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() call is blocking.
Hi, since we're implementing the new PM Version in CapFrameX we saw a strange behaviour regarding the CPUBusy metric.
What I'd expect CPUBusy and GPUBusy to show in different scenarios:
CPU Limit at 50FPS with the GPU able to reach 100FPS: CPUBusy - 20ms GPUBusy - 10ms
GPU Limit at 50FPS with the CPU able to reach 100FPS: CPUBusy - 10ms GPUBusy - 20ms
FPS Limit at 50FPS with both CPU and GPU able to reach 100FPS CPUBusy - 10ms GPUBusy - 10ms
If that is how it's supposed to be, we could create an overlay entry showing if the users FPS are limited by CPU(CPUBusy ~ avg frametime and GPUBusy < CPUBusy) GPU(GPUBusy ~ avg frametime and CPUBusy < CPUBusy) FPS limiter(CPUBusy and CPUBusy < avg frametime)
With an Intel and AMD System we saw the behaviour above: ~12.3ms GPUBusy that match the 82FPS and 3.9ms CPUBusy.
but with my AMD+Nvidia System for example it looks like this in a GPU limit
and this with an FPS limit
My CPUBusy times are always just a tiny bit lower but basically the same as my current frame times, regardless of the scenario
The examples above would then look like this on my system
CPU Limit at 50FPS with the GPU able to reach 100FPS: CPUBusy - 20ms GPUBusy - 10ms
GPU Limit at 50FPS with the CPU able to reach 100FPS: CPUBusy - 20ms GPUBusy - 20ms
FPS Limit at 50FPS with both CPU and GPU able to reach 100FPS CPUBusy - 20ms GPUBusy - 10ms
If it's like this, we don't really have anything to gain from the CPUBusy metric, so I don't think it's supposed to be like this.