GPU not at 100%: how to tell a CPU bottleneck from something else

Your overlay says the graphics card is at 60% and the frame rate is lower than you expected. Somebody tells you it is a CPU bottleneck, and you start reading about processors.

Maybe. But "GPU below 100%" has at least eight explanations, most cost nothing to check, and a real CPU limit is only one of them. This page rules them out one at a time.

First, what that percentage actually is

GPU usage is the share of time the GPU had work in flight — not how hard it worked. A card idling through a trivial workload can read 100% because something was always queued, and a card doing everything asked of it can read 60% because the queue kept running dry. A first clue and nothing more: on its own it cannot tell you what the GPU was waiting for.

The experiment that settles it in two minutes

Do this before anything else, because it is free and decisive.

1. Note your frame rate in a repeatable scene.
2. Drop the resolution substantially — not one step, a big step.
3. Measure the same scene again.

If the frame rate barely moves, the GPU was not your limit. You removed most of its work and got nothing back, so something else was setting the pace.

If the frame rate rises roughly in proportion, you were GPU-limited after all and the usage figure was misleading you.

That is the whole diagnosis, and it needs no tools. Everything below identifies what that is.

The cheap explanations, in order

1. You are at a cap

If the number you land on is exactly your refresh rate, your in-game frame limit, a driver-side limit or a latency feature's automatic cap, nothing is bottlenecked — the GPU is idle because you told it to stop. A false alarm, and ten seconds to rule out.

2. The card is being held back, not left idle

A GPU that is not boosting is not the same as a GPU that has no work. Under load the driver itself will name why it is holding clocks down: thermal protection, a power limit set below stock, an application that asked it to slow down, or a PCIe power connector missing or not seated. The last is a card that refuses to boost until it is plugged in properly — a cable problem, not a setting. The stutter scan asks the driver this under a short load and reports the reasons it named.

3. The game was restricted to part of the processor

Invisible unless you go looking. A narrowed affinity mask or a default CPU set on the game process means everything the game does has to fit on those processors while the rest of the machine sits idle. Sources include an old optimizer script, a start /affinity shortcut copied from a forum, or a process tool configured once and forgotten.

How you tell: Task Manager → Details, right-click the game, Set affinity. If it is not every processor, that is your answer — widen it there, or remove the rule in whatever tool wrote it.

4. The game is running on the wrong graphics card

On a laptop, or a desktop with integrated graphics enabled, a game can end up rendering on the weaker adapter. The discrete card then reports low usage honestly: it is not doing anything. Which GPU a game runs on covers removing a per-game preference.

5. The PCIe link is narrower than it should be

Worth checking once, and worth keeping in perspective. Half the lanes at the same generation can be the board's own design — an M.2 drive fed from the processor's lanes splits the graphics slot — and halving the link does not halve the frame rate; how much it costs on your card has not been measured here. The case worth acting on is a link that trained lower than both ends support: a riser, a marginal contact, a lane that did not come up. Reseat the card.

6. The GPU is waiting for data, not for the CPU

A frame that is not assembled yet leaves the GPU idle, and the reason may be a slow asset read, a shader being compiled, or pages coming back from disk. In a usage graph this looks identical to a CPU limit and is a different problem — see sudden FPS drops in games.

7. Something else has the core the render thread needs

Total CPU usage is the wrong number here. One fully saturated core on an eight-core machine reads as a modest total, and a background task holding that core queues ahead of the render thread.

What a real CPU limit looks like

When the list above is exhausted, the remaining case is genuine and has a recognisable shape:

• The resolution test did nothing. This is the requirement, not one signal among several.
• One thread is near saturation while the total is unremarkable. Look per-core; the total will never show you this.
• It gets worse with simulation, not with visuals. Crowds, physics, player counts, draw distance — not texture quality or shadow resolution.
• Frame times are stable but sitting on a floor. A CPU limit is a ceiling on throughput rather than a source of spikes; if your problem is spikes, read high average FPS but bad 1% lows instead.

A capture also records how much of the run was spent blocked inside the presentation call — that is GPU and queue pressure, and the higher it is, the less any change in average FPS says about anything on the CPU side. Reading the benchmark covers the rest.

What to do about a real CPU limit

The honest answer is that this is mostly not a software problem, and pages that pretend otherwise are how people end up with registry lists.

• Enable the memory profile in firmware (XMP on Intel, EXPO on AMD) if it is not on. Of everything in this area it is the one item with real published measurement behind it, and a machine running its memory at fallback speed is a common finding. Clean Install for Stable 1% Lows covers it with sources — including why buying faster memory is a different claim from enabling what you already have.
• Spend the headroom instead of chasing it. If lowering the resolution changed nothing, raising visual settings is free.
• Lower the simulation-side settings, which are the ones actually costing you.
• Make sure nothing is restraining the process — the affinity check above, and any job object or priority rule left behind.

What will not help

Disabling simultaneous multithreading or efficiency cores: the numbers behind that advice come from sources that published no method, so you would trade known multi-core capacity for an unverified gain. Kernel memory-management values and timer-resolution overrides: refused outright here, unmeasured everywhere. Memory cleaners: on a machine that is not short of memory, freeing more changes nothing measurable.

Related

• Sudden FPS drops in games
• High average FPS but bad 1% lows
• Which GPU a game runs on
• Clean Install for Stable 1% Lows