How to Use PresentMon GPU Busy to Diagnose Gaming Bottlenecks

Why GPU usage alone falls short​

GPU usage isn't a per-frame measurement. Rozario's point is that the percentage in tools like MSI Afterburner reflects how busy the GPU was over a sampling interval. Short stretches where the GPU sat idle waiting for work can disappear into that average. This is the author's explanation. PresentMon's documentation doesn't specify how any particular overlay samples its numbers, so treat it as a general caution rather than a measured fact about one tool.

A low reading is also ambiguous. The article lists several non-CPU causes of reduced GPU utilization:

• V-Sync
• an FPS cap
• game engine limits
• slow memory

A 70–80% reading therefore shows only that the GPU wasn't saturated. It doesn't show why.

What GPU Busy actually is​

PresentMon's own metric definitions are more precise than most summaries. They describe several related per-frame values:

• Frame Time: the total time between frames on the CPU.
• GPU Busy: how long the GPU spent working on that frame.
• GPU Wait: time the GPU spent waiting while working on the frame.
• GPU Time: the span from when the GPU started the frame to when it finished. The documentation notes the GPU may not have been fully busy during that span.
• CPU Busy and CPU Wait: how long the CPU spent generating the frame, and how long it waited before it could start.

PresentMon also reports GPU Utilization as a separate metric, described as the amount of GPU processing capacity in use. GPU Busy is a duration in milliseconds, while utilization is a capacity figure, so the two measure different things.

Independent coverage describes the idea the same way. TechSpot's PresentMon guide says that when Frame Time is much longer than GPU Busy, performance is being limited by things like CPU speed. Its worked example attributes the rest of the frame time to the CPU, RAM, the OS and the game itself, not to the CPU alone.

Reading the numbers: the 150 FPS example​

Rozario's example is simple arithmetic:

1. 150 FPS works out to about 6.67 ms per frame (1,000 ÷ 150).
2. If GPU Busy is about 6 ms, the GPU is occupied for nearly the whole frame interval, so you're probably GPU-bound.
3. If GPU Busy is about 4 ms, there's a gap of roughly 2.67 ms between GPU Busy and frame time.

If a similar gap shows up across many frames, it could point to a CPU bottleneck. But the author warns against assuming the CPU spends that remaining time preparing the next frame, because CPU and GPU workloads can overlap. These figures are illustrative, not benchmark results.

Think of a restaurant kitchen. The oven (the GPU) being free doesn't prove the prep cook (the CPU) is the slow one. The orders might have stopped coming in, or the manager might be metering them out (a frame cap).

A practical test routine​

The article's workflow, combined with PresentMon's metrics, gives a sensible procedure:

1. Check the obvious limiters first. Turn off or account for V-Sync and FPS caps. A capped game will show GPU Busy well below frame time without any CPU problem.
2. Pick a repeatable scene. Use the same location or benchmark pass each time so results are comparable.
3. Watch GPU usage as a quick alarm. Rozario still keeps it running, since it flags that something is off.
4. Cut the GPU's workload. Lower the resolution, reduce GPU-heavy settings or enable DLSS.
5. Compare the outcome. If GPU Busy falls but frame rate barely improves, the GPU wasn't the only limit. In the author's words, you've probably hit the CPU's limits. It's still evidence, not proof.
6. Open PresentMon and plot Frame Time next to GPU Busy. Look across many frames, not at a single moment.
7. Add CPU Busy and CPU Wait where available. They give additional context that GPU Busy alone cannot.

Another guide covering PresentMon bottleneck testing suggests a similar reading. If both CPU and GPU busy times sit well under the frame time, a limiter or other constraint is probably capping you.

Caveats you should know about​

PresentMon's own repository documents limits that matter for small gaps:

• Hardware-Accelerated GPU Scheduling (HWS). With HWS enabled, GPU execution metrics can be less accurate. The documentation gives an example where, in a GPU-bound case, the reported GPU active time may be about 0.5 ms larger than the true GPU work duration. The amount depends on workload and GPU, and an improved solution was listed as work in progress. On a 6.67 ms frame, half a millisecond is not trivial.
• OpenGL and Vulkan. Applications reported with runtime "Other," typical of OpenGL or Vulkan, have less instrumentation. CPUFramePacingStall always reports 0 and CPUFrameTime may be slightly less accurate. That also affects some latency calculations.
• Displayed vs. presented FPS. PresentMon distinguishes the rate at which frames change at the display from the rate of application Present() calls. If your numbers seem inconsistent, check which one you're reading.

Another wrinkle comes from GamersNexus' discussion with Intel engineer Tom Petersen. It notes that PresentMon 2.0 added GPU Wait so users can see inside GPU Busy. A GPU can look "busy" while still waiting on the CPU between rendering operations. So even a high GPU Busy value deserves some scrutiny.

Not an Intel-only trick​

Despite the branding, this isn't limited to Intel hardware. PresentMon is an open-source (MIT-licensed) toolset for Windows. It traces CPU, GPU and display timings across DirectX, OpenGL and Vulkan, for both desktop and UWP apps. Its capture application provides a real-time overlay and per-frame CSV capture. The project lists other tools built on the same foundation, including CapFrameX, AMD OCAT, RivaTuner Statistics Server and NVIDIA FrameView. CapFrameX's release notes show it added a GPU Busy metric and graph in 2023, along with a "GPU Busy Deviation" overlay value. Not every monitoring app exposes the metric the same way, so check each tool's definition.

If PresentMon fails with an "access denied" error when starting a trace, its documentation says the user must belong to the "Performance Log Users" group. Without administrator privileges, short-lived or other-user processes may show as "<unknown>."

Bottom line​

GPU Busy is a better diagnostic than a utilization percentage because it ties GPU work to each frame's time budget. Even so, it is a clue, not a verdict. The author's own examples, a Ryzen 7 9800X3D with an RTX 4090 in Valorant, are personal observations and not independent test data. They illustrate that some games are simply engine-limited. The sensible approach is the one Rozario ends on: start with GPU usage, test by changing GPU load, then bring in GPU Busy, and rule out caps, V-Sync, memory and engine behavior before you blame, or buy, a new processor.