Quick answer: CPU-bound means your CPU is the bottleneck limiting frame rate (logic, physics, draw calls); GPU-bound means your GPU is (rendering, shaders, overdraw). They need opposite optimizations, so determine which you are first.
When your game is slow, it's limited by either the CPU or the GPU, and which one determines how you should optimize. Optimizing the wrong one wastes effort. Here's the comparison and why identifying your bottleneck comes first.
What CPU-Bound Means
CPU-bound means your CPU is the bottleneck, it can't keep up, limiting your frame rate, while the GPU has spare capacity. CPU work in games includes game logic, physics, AI, pathfinding, and issuing draw calls. If frame drops coincide with heavy logic (many entities, complex simulation), you're likely CPU-bound.
When CPU-bound, the fix is reducing CPU work: optimizing logic, moving work off the main thread, spreading it across frames, or reducing draw calls. Bugnet captures performance data from real sessions so you can see when frame drops align with heavy CPU load. Throwing GPU optimizations at a CPU-bound game does nothing.
What GPU-Bound Means
GPU-bound means your GPU is the bottleneck, it can't render fast enough, while the CPU has spare capacity. GPU work is rendering: drawing pixels, running shaders, handling overdraw and effects. If frame drops coincide with heavy rendering (lots on screen, complex shaders, many effects), you're likely GPU-bound.
When GPU-bound, the fix is reducing rendering cost: cutting overdraw, simplifying shaders, reducing resolution or effects, batching draws. Bugnet's performance data helps you see when frame drops correlate with rendering load. Optimizing CPU work on a GPU-bound game won't help, since the GPU is the limit.
Why Identifying Your Bottleneck Comes First
CPU-bound and GPU-bound need opposite optimizations, so the most important step is determining which you are before optimizing. Many games have been mis-optimized by guessing wrong, spending effort on rendering when the CPU was the limit, or vice versa, with no improvement because the actual bottleneck was untouched.
Determine it by checking what your frame drops coincide with (heavy logic vs heavy rendering) on real hardware. Bugnet captures performance with context, helping you tell which. So always identify whether you're CPU-bound or GPU-bound first, then apply the matching optimization, since fixing the wrong bottleneck wastes effort entirely.
CPU-bound means the CPU limits your frame rate (logic, physics, draw calls); GPU-bound means the GPU does (rendering, shaders, overdraw). They need opposite fixes, so identify which you are first, or you'll optimize the wrong thing.