To find whether CPU or GPU limits your FPS, repeat the same game scene at your usual settings and at a substantially lower render resolution, while recording FPS, frame times and relevant utilization. Compare several runs, not one screenshot. If FPS improves consistently when GPU work falls, the original setup was at least partly graphics-limited. If it barely changes, investigate CPU, engine, caps and other limits; low GPU use alone does not prove you need a new processor.

A PC does not have one permanent “bottleneck percentage.” The limiting work changes with the game, scene, settings and target frame rate. Intel’s profiling guidance describes both CPU/GPU dependencies and scene-dependent limits.

Decide what problem you are measuring

Write down your goal: steadier frame delivery, a higher average FPS, or hitting your monitor’s chosen refresh rate. They are related, but not interchangeable. A system already maintaining a comfortable capped frame rate may have no practical upgrade problem.

FPS counts frames per second. Frame time measures the time between frames; uneven delivery can feel poor even with a respectable average. Use the same tool and statistic in each comparison. Different tools’ “1% low” calculations and capture windows need not match.

Record the exact CPU, GPU, RAM configuration and game version. Our PC specifications guide can help. On a laptop, confirm which GPU the game actually uses and keep power/thermal mode consistent.

Prepare a comparison that answers one question

Choose a built-in benchmark or a repeatable route in a local save. A changing online match, different player count or loading screen is a poor comparison. Let shader compilation and initial loading finish, and run through the scene before recording it.

Record your ordinary settings first. For the short diagnostic comparison, use the same state for FPS caps, V-Sync, frame generation and dynamic resolution. If safe and supported by the game, temporarily remove the FPS cap/V-Sync cap and turn off frame generation and dynamic resolution to expose the underlying rendering limit. Restore your normal settings afterward. You do not need to disable anti-cheat or security software.

Frame generation adds displayed frames, so mixing it across runs confuses base-rendering comparisons. Dynamic resolution changes render workload automatically; a fixed output resolution alone does not mean a fixed render resolution.

Use one supported overlay/logger rather than several competing overlays. AMD’s metrics guide explains its Performance Metrics and logging options on supported full installations. NVIDIA FrameView is another official measurement route; check its current support and metric definitions. In-game CPU/GPU timing displays can also help where available.

Run an A/B/A resolution test

  1. A: normal render resolution. Record the same 60–90 second section if the scene allows it. Capture FPS/frame-time behavior, GPU utilization/clock/temperature, CPU load and any visible stutters.
  2. B: lower render resolution only. Keep the route, preset, texture settings, ray tracing, crowd/view-distance settings and power mode unchanged. Reduce render resolution substantially, such as 2560×1440 to 1920×1080, or use a clearly recorded lower fixed render scale. These are example settings, not measured results.
  3. Repeat both settings. Use at least a few comparable runs and return to A. If the second A performs differently because the laptop heated up or a background task started, do not attribute the whole difference to resolution.

Use the same capture length and tool. Do not invent a universal “10% improvement means GPU bottleneck” threshold. The difference should be repeatable and larger than ordinary run-to-run variation before it supports a decision.

Interpret the pattern, including inconclusive results

Lower resolution reliably improves FPS

This supports a GPU/render-work limit at the original settings, especially if GPU activity was consistently high during that scene. It does not prove every scene is GPU-limited or predict the gain from a particular replacement card. Try the graphics options you can accept before spending money.

FPS stays similar while GPU activity falls

The next limit may be CPU work, an engine limit, an overlooked cap or another system condition. CPU usage does not need to reach 100% overall: a game can depend heavily on a subset of its threads. A single busy logical core is also not conclusive proof, because scheduling and sampling vary.

Check repeatable CPU-heavy scenes or settings separately. Lowering crowd or simulation settings can be informative where the game exposes them, but change one setting at a time and do not assume every game’s “draw distance” option affects only the CPU.

FPS sits exactly near a configured limit

A cap or synchronization setting may be doing its job. Low CPU/GPU load below a deliberate ceiling is not wasted hardware that must be fixed. Decide whether you actually want the extra heat/noise of a higher target.

Average FPS looks fine, but stutters remain

Inspect frame-time behavior and when the stutters happen. Shader compilation, asset streaming, background work, memory pressure, thermal/power limits or the game itself may be involved. VRAM allocation near capacity is a clue, not proof of exhaustion. Test a lower texture setting separately if that matches the symptom.

Network delay and rubber-banding are another question: a faster CPU or GPU is not a general cure for packet loss. If the runs vary widely, the result is inconclusive, not permission to select a component at random.

Resolution test: separate a change from a noisy run

A fast result is useful only if it survives a repeat. Enter average rendered FPS from the same scene; generated/displayed FPS is not interchangeable. Keep settings and capture length fixed.

At a constant rate, 60 FPS allows 16.67 milliseconds per frame and 120 FPS allows 8.33 milliseconds. The second frame-time bar is half as long.
Arithmetic reference, not measured frame times: the average budget halves when FPS doubles.
  1. A · Usual resolution

    Warm up the scene. Record FPS, frame times, caps and GPU telemetry.

  2. B · Lower render resolution

    Change only render resolution. Keep textures, crowds and ray tracing unchanged.

  3. A · Return to baseline

    Repeat the original settings. A different result here exposes drift.

Worked example — invented numbers, not a hardware test

A1: 60 FPS → B: 90 FPS → A2: 62 FPS. The return run stayed close to the starting run, while B gained substantially. This supports a graphics-workload limit in this scene, provided caps, frame generation, dynamic resolution and power conditions were controlled. It does not predict the FPS of a replacement GPU. Now compare A1: 60 → B: 64 → A2: 68: B sits inside the two baseline results. Heat, background activity or a changing scene could explain it; collect more repeats before deciding.

Runs only in your browser. Nothing is uploaded or saved. Use the written method above to collect the right readings.

Frame-time reference: 60 FPS averages 16.67 ms per frame; 120 FPS averages 8.33 ms. An average hides long frames. Compare the timeline, not just the headline FPS.

Avoid reading the wrong utilization graph

In Task Manager → Performance, select the actual gaming GPU and the relevant engine. Microsoft explains GPU engine reporting: Copy, Video Decode and 3D are different workloads, and an aggregate percentage can represent the busiest engine. GPU 0 is not automatically the faster card.

Task Manager is useful context, but switching out of a game can change its workload. Prefer an in-game log for the captured scene. Likewise, a falling clock with rising temperature warrants cooling/power investigation before a hardware shopping decision; temperature alone does not establish throttling without the model’s limits and accompanying behavior.

Keep the evidence for an upgrade decision

Game/version / scene / target FPS and refresh rate:
CPU / GPU / RAM / laptop power mode:
Tool / metric definitions / capture length:
Caps / V-Sync / frame generation / dynamic resolution:
A: render resolution / FPS / frame-time pattern:
B: render resolution / FPS / frame-time pattern:
Repeated runs / normal variation / return-to-A result:
GPU activity / clock / temperature; CPU context:
Stutters, background work or other confounders:
Likely limit / uncertainty / next single check:

Use Copy to AI to share the completed record with a support tool; the empty template alone cannot diagnose your PC. Once a repeatable limit is established, compare independent tests for your games and settings. Our 1080p GPU guide provides graphics-selection context; a hardware-name calculator cannot substitute for this experiment.

Common questions

Is 99% GPU use harmful?

High utilization while rendering an uncapped game can simply mean the GPU is busy. It is not, by itself, evidence of a fault. Evaluate temperatures, stability and whether the experience meets your goal.

Can both CPU and GPU limit performance?

Yes. A run can contain different limits in different frames or scenes. The resolution test narrows the question for the captured workload; it does not certify the whole PC.

Will a faster SSD raise my average FPS?

Do not infer that from a loading pause or disk activity alone. Storage-related loading/streaming problems and a sustained rendering limit need separate evidence.