This is a first-person account, so the RTX 4090 setup and the "years of use" are the author's own claims. They aren't benchmark results. The metric definitions, though, are documented by Intel's PresentMon project, and they hold up. Here is what GPU Busy measures, how to read it, and where it can mislead you.
Why GPU usage alone can mislead
The author's core argument is that GPU usage is a sampled percentage. It shows how busy the GPU was over a sampling period. It doesn't describe what happened inside any single frame.
GPU Busy, by contrast, is a per-frame time in milliseconds. If it stays close to frame time, the GPU is spending most of the frame interval rendering. In the author's example, 9.5 ms of GPU Busy against a 10 ms frame time suggests you're GPU-bound, much like a pinned 99% usage reading.
The arithmetic is simple. 100 FPS means 1,000 ms ÷ 100 = 10 ms per frame.
The PresentMon documentation separates these ideas cleanly:
- Frame Time: the total time between frames on the CPU.
- GPU Busy: how long the GPU spent working on that frame. The console documentation adds that this is time when at least one GPU engine is executing work from the target process.
- GPU Time: the span from when the GPU started the frame to when it finished. The GPU may not be fully busy throughout that span.
- GPU Utilization: the share of GPU processing capacity in use. It is a different kind of measurement from per-frame busy time.
- CPU Busy and CPU Wait: how long the CPU spent generating the frame, and how long it waited before it could start the next one.
Reading the gap between GPU Busy and frame time
The useful signal is the gap. The author says GPU Busy of only 6 ms against a 10 ms frame suggests the GPU may be waiting on something else. They warn against assuming the CPU fills the other 4 ms, because CPU and GPU work can overlap.
Other coverage reaches the same conclusion. TechSpot's PresentMon guide says that if frame time is much longer than GPU Busy time, factors such as CPU speed are limiting performance. The same guide cautions that frame-time spikes aren't always a CPU bottleneck and can come from causes outside a single piece of hardware.
That caution matters. A gap is a clue, not a verdict. Possible causes include:
- an FPS cap or V-Sync
- engine or synchronization limits
- memory behaviour
- the CPU itself
XDA's companion piece on the same metric makes the same point. GPU Busy, like GPU usage, can't pinpoint a CPU bottleneck, but it helps you narrow things down.
A practical way to try it
Here is a cautious workflow built from the author's approach and PresentMon's documentation. I haven't tested it myself.
- Rule out limiters first. The author checks for an FPS cap and V-Sync before blaming hardware.
- Start PresentMon. The capture application is launched by running
PresentMon.exe. It works as both a real-time overlay and a trace-capture tool. - Plot Frame Time and GPU Busy together. Seeing them on one graph is the author's main reason for liking the tool.
- Add CPU Busy. The author says you can create a custom preset and place CPU Busy beneath GPU Busy on the same frame-time graph. That gives you three lines to compare.
- Use a repeatable scene. Keep settings and location the same. A single spike shouldn't be treated as a persistent limit.
- Interpret cautiously.
- GPU Busy close to frame time suggests the GPU is the limiting factor. Lowering GPU-heavy settings is a reasonable test.
- A consistent large gap suggests you look elsewhere, such as the CPU, memory, or the game engine.
- If both CPU Busy and GPU Busy sit well under frame time, a limiter or other constraint may be at work. This reading comes from a guide cited on WindowsForum.
Saving data for later
PresentMon's capture application can save results. Per the project documentation, each capture produces two CSV files: raw frame data, and a summary with capture duration, total frames, and average, minimum, maximum, 99th, 95th and 90th percentile FPS. Files are stored in the user's local AppData folder under Intel\PresentMon\Capture.
That makes it possible to compare a before-and-after change, such as a new setting or a CPU swap, with numbers rather than impressions.
Afterburner isn't going anywhere
The author isn't dropping MSI Afterburner. They keep it for a heavily customised overlay and for GPU tuning. That includes an RTX 4090 undervolt profile, power-limit changes and a custom fan curve. Afterburner and RTSS stay as the everyday overlay. PresentMon comes out when something looks off, usually when GPU usage is lower than expected.
That split makes sense. Afterburner is a tuning utility with a monitoring overlay. PresentMon is a measurement tool that happens to show an overlay. Nothing in the evidence suggests one is universally more accurate or that either replaces the other.
Caveats
- The article's examples are illustrative figures, not reproducible tests.
- The companion XDA piece still recommends checking GPU usage first, because it's straightforward and familiar. The best reading of the evidence is that GPU usage is a starting point and GPU Busy is a second look.
- Some PresentMon metrics are marked as dynamic, frame-event or static queries. Others can depend on hardware support. Don't assume every metric is available on every system.
- One guide I came across makes a blunt rule of thumb: CPU Busy above GPU Busy means a CPU bottleneck. I wouldn't treat that as gospel, given the overlap between CPU and GPU work.
Bottom line
Seeing "GPU at 80%" and guessing is a weak way to diagnose performance. PresentMon's value is that it plots how long the GPU actually works on each frame against how long the frame takes. That narrows down where to look next.
It won't hand you a definitive culprit. For anyone already comfortable with an Afterburner overlay, though, it's a free, open-source second opinion for the moments when the numbers don't add up.