CPU and GPU frame profiling: finding the limiting work

Start with a repeatable question

A low frame rate is an observation, not a diagnosis. Choose a scene and a player action that reproduce the problem, then state the performance target. A crowded combat encounter and opening an inventory may have different causes even when both feel slow. Keep their captures separate so one average does not conceal two unrelated problems.

Read overlapping timelines

CPU simulation, render submission and GPU execution can overlap. Unity's Highlights module therefore compares CPU active time and GPU time individually with the target frame budget. Its active-time calculation removes specific waiting markers. [1] Inspect the surrounding timeline before interpreting a long wait: the thread may be waiting for another stage or for presentation scheduling. A timer's name alone does not identify useful computation.

Work through a frame budget

For an illustrative target of 60 frames per second, the budget is about 16.67 ms. Suppose a representative frame has 10 ms of CPU work and 14 ms of GPU work. Adding them to claim a 24 ms frame ignores possible overlap. These invented measurements also do not guarantee a 14 ms presentation interval: dependencies, synchronization and pacing still matter.

Now suppose lowering rendering resolution reduces GPU time while CPU work stays similar. That is evidence to investigate pixel-related work, not proof that a particular shader is responsible. Compare individual passes before selecting an optimization.

Capture a controlled comparison

Use a build on representative target hardware. Record engine version, graphics API, resolution, quality settings and power conditions. Repeat the same camera route, including asset loading and effects that players actually encounter. Keep first-use captures separate from warmed steady-state captures.

Change one relevant variable, collect several runs and inspect the distribution of frame times, including slow outliers. Correlate spikes with CPU tasks, GPU passes, allocations and loading events. Preserve the capture and the exact configuration so another developer can reproduce the comparison. Report the observed interval and workload instead of presenting one favourable frame as a general speedup.

Account for measurement limits

Instrumentation changes the workload. Unity's Frame Timing Manager is deliberately narrower than a general profiler and is designed for lower overhead, but its measurements still have platform limitations. [2] Confirm that the selected counter is supported and valid.

After a change, check visual output and gameplay as well as timings. A shorter pass can move the bottleneck elsewhere. Track frame pacing and input response separately; a smooth throughput graph does not by itself establish low end-to-end latency.

Sources

[1] Highlights Profiler module reference — Unity Technologies.

[2] Detecting performance bottlenecks with Unity Frame Timing Manager — Anton Kruglyakov, Unity Technologies.