CPU vs GPU Bottleneck Calculator

Frame time is the useful starting point

Frames per second is the reciprocal of frame time. When time is measured in milliseconds:

frame-rate ceiling = 1000 / frame time in ms

The slower measured stage sets the simplified pipeline ceiling:

estimated ceiling = 1000 / max(CPU frame time, GPU frame time)

This is a diagnostic estimate, not a promise that the game will present frames at exactly that rate. Frame caps, synchronization, queues, engine work, loading, operating-system scheduling and display presentation can all affect observed FPS. Microsoft defines CPU time per frame and GPU time per frame separately in its DirectX profiling guidance because either side can exceed the available frame budget.

The 1000 / ms conversion is a ceiling for the measured stage. For example, a 12 ms CPU time corresponds to about 83.33 FPS, while a 7 ms GPU time corresponds to about 142.86 FPS. In that capture, the CPU side is slower and the simplified ceiling is about 83.33 FPS.

Why the tolerance matters

Close frame times should not be reported with false certainty. This calculator compares the absolute gap with the slower frame time:

relative gap = |CPU ms - GPU ms| / max(CPU ms, GPU ms) × 100

If that gap is inside your selected tolerance, the result is balanced or indeterminate for this capture. If it exceeds the tolerance, the side with the longer frame time is the current limiting side.

This percentage describes the separation between two timings in one workload. It is not the percentage of the CPU or GPU that is wasted, and it does not predict the performance gain from changing hardware.

Make the capture reproducible

A useful comparison keeps the workload stable. Use the same:

• game and engine build;
• save, replay, benchmark sequence or fixed movement route;
• resolution, render scale, quality preset and graphics API;
• frame cap, VSync and dynamic-resolution state;
• driver settings, power mode and background workload;
• warm-up period and capture duration.

Run the test several times and compare representative statistics instead of trusting one short sample. AMD’s CPU performance guidance recommends fixing variables such as the test scene and random seed, while its Unreal Engine guidance suggests changing resolution as a diagnostic: if a much higher rendering resolution barely changes performance, that is evidence worth investigating for a CPU-side limit in that workload. It is still evidence, not a universal verdict.

Why utilization is not proof

Utilization can support a diagnosis but cannot establish one by itself. Total CPU utilization may look modest while one main or render thread is saturated. Low GPU utilization may come from a frame cap, a wait on the CPU, synchronization or too little submitted work. High GPU utilization says that the device was busy; it does not identify the exact expensive pass or predict an upgrade result.

Timing tools provide better context. Intel PresentMon records frame and GPU telemetry, NVIDIA Nsight shows CPU and GPU frame durations and GPU workload ranges, and AMD Radeon GPU Profiler visualizes queue timing and GPU idle periods. Even profiler thresholds are heuristics: Radeon GPU Profiler’s CPU-bound classification uses an adjustable GPU-idle threshold rather than a law that applies to every engine.

What 1% lows can and cannot tell you

A 1% low summarizes the slow tail of a frame-time distribution, so it is useful for spotting uneven delivery that an average can hide. It does not reveal whether the CPU, GPU, asset streaming, shader compilation, memory pressure or another stall caused those slow frames.

Definitions also vary. Some reports derive a rate from the 99th-percentile frame time (1000 / p99 frame time), while others average the slowest 1% of FPS samples. NVIDIA Nsight Systems defines its 99th-percentile frame length as the value for which only 1% of frames are longer. Record the tool and definition when comparing results, and do not substitute a 1% low value for matching CPU and GPU frame times.

Why universal bottleneck percentages are misleading

A computer does not have one permanent CPU/GPU bottleneck ratio. The limiting work can change with the game, scene, resolution, settings, engine version, driver, frame cap and target frame rate. A busy city scene may stress simulation and draw-call submission, while a different scene at a higher render scale may spend more time on the GPU.

Model-name calculators cannot observe those conditions. A result such as “23% bottleneck” without measured, same-scene timing has no stable technical meaning. Use this calculator to describe the capture you actually made, repeat the test under the workload you care about, and use a timeline profiler when you need to find the specific work responsible.

Official technical references

• Microsoft: Profiling DirectX applications
• Intel: PresentMon performance monitoring
• NVIDIA: Nsight Systems frame health
• NVIDIA: Nsight Graphics GPU Trace
• AMD GPUOpen: Radeon GPU Profiler overview
• AMD GPUOpen: Unreal Engine performance guide
• AMD GPUOpen: Ryzen CPU performance guide