Game Performance

Systematic methodology for diagnosing and fixing game performance problems. Profile first, fix the root cause, leave headroom.

Core Principles

• Profile before optimizing. Measure, don't guess. The bottleneck is almost never where you think it is. Every optimization session starts with a profiler, not a hunch.
• Fix the root cause, not the symptom. Upscaling masks fill-rate problems but doesn't fix them — you still pay the thermal and battery cost. Fixing the source gives you FPS gains and thermal/battery gains.
• Isolate variables. Change one thing at a time, observe the metric, conclude. Changing three things simultaneously makes it impossible to know which one helped.
• Leave headroom. Never target 100% utilization. Background OS tasks, worst-case game moments (explosions, many entities), and thermal variance all eat into margin. Target 60–75% utilization at your FPS goal on min-spec hardware.
• Utilization ≠ performance. ~29% GPU at 1600MHz delivers the same FPS as 55% GPU at 830MHz — with roughly half the power draw. When the hardware has spare capacity, it downclocks to save power. Lower utilization at a lower clock is better than high utilization at a high clock.
• Flat profiles are the mature case. Jonathan Blow observes that once obvious hotspots are eliminated, a mature profile is "flat" — many items each at ~0.3–1%, no single dominant win. If one change does give a huge speedup at that stage, you were probably previously negligent. Your options become "accept the profile" or "make an architectural change"; grinding down many small contributors is the expensive, incremental reality. The diagnostic decision tree below assumes a hotspot exists; this principle covers the flat case where it doesn't.
• Measure work per unit time, not raw throughput. Don't compare raw rates (fps, draw calls/sec) across different workloads — compare work and features delivered per unit time. A rich scene running at 120fps and an empty room running at 2000fps are not comparable; the empty room number tells you nothing about your game's actual budget. Evaluate performance in the context of what is being rendered.

Performance Glossary

The Diagnostic Decision Tree

This is the core of the skill. Follow the numbered steps in order. Each test isolates one variable and tells you where to look next.

Step 1: Establish Baseline Metrics

Before touching anything, record:

• FPS (average and 1% low)
• GPU utilization % and GPU clock speed
• CPU utilization % per core
• VRAM usage and system RAM usage
• Frame time graph over 30+ seconds (not just average FPS)

Critical question: Is the problem sustained low FPS, intermittent hitches, or both?

• Sustained low FPS only → proceed to Step 2
• Intermittent hitches only → proceed to Step 5
• Both → Step 2 first (fix the sustained bottleneck), then return to Step 5

Step 2: Sustained Low FPS — Identify the Primary Bottleneck

Compare GPU utilization vs. CPU utilization:

Note: If your engine uses a separate render thread (Godot 4, Unity multithreaded rendering), check render thread utilization separately from main thread utilization.

Submission-bound is a special case: the CPU is spending its budget generating draw calls and state changes, so the GPU starves. It looks like both are high, but the GPU has "bubbles" — it's not actually running at capacity. The fix is on the CPU side (batching, instancing) not the GPU side.

Step 3: GPU-Bound — Classify the GPU Bottleneck

Test A: Halve render resolution (set render scale to 0.5×)

Mobile/TBDR caveat: On tile-based GPU architectures (all iOS, most Android — Mali, Adreno, PowerVR), internal framebuffer bandwidth is handled on-chip. Halving resolution may show little improvement even when texture bandwidth is the bottleneck. On these platforms, proceed to Test B regardless of Test A result.

• GPU load drops significantly → fill-rate or bandwidth bound
  • Test B1: Replace textures with solid-color constants (keep shader math, remove texture reads — use a hardcoded vec4(1.0) in the shader instead of a texture sample)
    • GPU load drops → bandwidth/texture bound → see references/gpu-profiling.md § Bandwidth
    • No change → shader ALU bound → see references/gpu-profiling.md § Shader Complexity
  • Test B2 (if B1 showed bandwidth-bound): Re-enable textures but use a single 1×1 solid-color texture for all materials
    • GPU load stays low → data bandwidth is the bottleneck (the sampler hardware is cheap; the data volume was the problem); proceed with compression and mip bias
    • GPU load returns to near-original → sampler-count or TMU-bound (too many texture units active regardless of data size); reduce distinct texture samples per pixel
• No change → fixed-cost overhead (resolution doesn't affect it)
  • Test C: Halve geometry count (aggressive LOD, or disable half the scene objects)
    • GPU load drops → vertex-bound → see references/gpu-profiling.md § Vertex
    • No change → compute passes, rogue cameras, or unnecessary render passes → see references/gpu-profiling.md § Fixed Overhead

Step 4: CPU-Bound — Classify the CPU Bottleneck

Open your profiler and identify which subsystem dominates frame time. Common categories: script/logic, physics, animation, audio, render thread submission.

Branch on language runtime:

[Managed: C#, GDScript, Lua]

1. Check GC allocation rate per frame first — GC spikes are the most common managed-language performance killer
2. If allocation rate is high, see references/cpu-profiling.md § GC Pressure
3. If allocation is low, check which subsystem dominates and see references/cpu-profiling.md for that subsystem

[Native: C++, Rust]

1. Check cache miss rate in hot loops first — pointer chasing and random memory access are the most common native performance killers
2. If cache miss rate is high, see references/cpu-profiling.md § Cache Inefficiency
3. If cache misses are low, check which subsystem dominates and see references/cpu-profiling.md for that subsystem

Step 5: Intermittent Hitches — Frame Pacing Investigation

Record a frame time graph over 60+ seconds. Characterize the pattern:

See references/cpu-profiling.md § Hitching for the full investigation per category.

Step 6: Thermal and Power Issues

• Target FPS met but utilization > 80% → headroom problem; see references/thermal-power.md § Headroom
• Performance degrades over a 20–30 minute play session → thermal throttling; see references/thermal-power.md § Thermal Throttling
• Battery drains too fast on handheld/mobile → power optimization needed; see references/thermal-power.md § Battery Life

Worked Example: Steam Deck GPU Bottleneck

Scenario: A 2D action game hits 60fps on Steam Deck but at 90% GPU utilization and 1600MHz clock speed. The developer wants to ship with headroom for worst-case scenes.

Step 1: Baseline metrics

• FPS: 60 (vsync-locked), 1% low: 58
• GPU: 90% utilization, 1600MHz
• CPU: 45% utilization
• Frame time graph: mostly flat at 16.6ms, occasional 18ms spikes

Conclusion: sustained GPU-bound problem. CPU has headroom. Proceed to Step 2.

Step 2: Primary bottleneck GPU ~90%, CPU ~45% → clearly GPU-bound. Proceed to Step 3.

Step 3: Classify GPU bottleneck

Test A: Set render scale to 0.5× (halve resolution).

• Result: GPU drops from 90% to 55%. Significant drop.
• Conclusion: fill-rate or bandwidth bound. Proceed to Test B1.

Test B1: Replace textures with solid-color constants in shaders (keep lighting math, remove texture reads).

• Result: GPU drops from 55% to 35%.
• Conclusion: bandwidth/texture bound. The texture reads are the bottleneck.

Test B2: Re-enable textures but use a single 1×1 solid-color texture for all materials.

• Result: GPU stays low at ~35% (same as B1 — the 1×1 texture does not bring load back).
• Conclusion: data bandwidth is the bottleneck (not sampler count). Proceed with compression and mip bias.

Investigation (from references/gpu-profiling.md § Bandwidth):

• Audit texture compression: several 2048×2048 textures were imported as uncompressed RGBA8. Converting to BC7 (desktop) / ASTC 4×4 (mobile) reduces texture memory bandwidth by 4–8×.
• Found two render targets using RGBA16F precision when RGBA8 was sufficient.
• Found a shadow map at 4096×4096 for a 2D game — reduced to 1024×1024.

Result after fixes:

• GPU: drops from 90% to ~60% utilization at 1600MHz
• DVFS kicks in: hardware downclocks to ~1100MHz where the same workload runs at ~80% utilization
• FPS: still 60fps (vsync-locked)
• Power draw: reduced by ~35–40%
• Thermal: chip now runs 10–12°C cooler; no throttling in 30-minute sessions

Key insight: The FPS didn't change, but the game is now thermally sustainable and has headroom for worst-case scenes. The fix was invisible to the player but critical for handheld shipping. The hardware chose a lower clock because the workload no longer required maximum clock to meet the frame budget.

References

Relationship to Other Skills

game-patterns — Architectural patterns that prevent performance problems: Object Pool (eliminate GC pressure), Data Locality (fix cache misses), Spatial Partition (reduce O(n²) queries), Dirty Flag (avoid redundant recomputation). Use game-patterns when you've identified the bottleneck category and need the implementation pattern. Use this skill to identify the bottleneck first.

godot / love2d — Engine-specific profiling tools and their configuration. This skill is engine-agnostic; your engine skill handles how to open the profiler, what the columns mean, and engine-specific optimization APIs.

godot-shader — Shader authoring and optimization. When this skill identifies shader complexity as the bottleneck, godot-shader handles the implementation of simpler or more efficient shaders.

Further Reading

• Intel Gen11 Developer and Optimization Guide — Deep dive into Intel integrated GPU architecture; general integrated GPU constraints apply broadly even though Steam Deck uses AMD RDNA2
• Valve Steam Deck Recommendations — Official guidance on performance targets, power profiles, and testing methodology for handheld
• Adrian Courrèges Graphics Studies — Frame-by-frame dissections of AAA games showing exactly what each render pass costs and why