Game & Graphics Performance Optimization Questions

Definition — short

• Eager loading: load assets up-front (at level load or app start). Example: preloading main character textures, common meshes, and UI audio during level load.
• Lazy loading: load on-demand when first needed. Example: stream in distant environment textures, rare weapon meshes, or voice lines when players approach.

Concrete examples

• Textures: eager = load UI atlas + player skins at scene start; lazy = stream high-res terrain tiles as camera nears.
• Meshes: eager = NPCs in starting area; lazy = boss model only when entering boss arena.
• Audio: eager = UI SFX; lazy = long dialogue files streamed on first play.

Pros / Cons

• Load latency: eager → higher initial load time; lazy → lower startup time but possible single-frame stall when first used.
• Memory usage: eager → higher peak memory; lazy → lower steady memory (but may need caching).
• Perceptible hitches: eager → fewer runtime hitches; lazy → risk of hitches unless streamed/loaded asynchronously and with prefetch.

When to choose

• Mobile: prefer lazy + streaming, aggressive eviction, async I/O, and smaller preloads to fit memory and reduce install/start times. Preload critical UI/controls eagerly.
• Console: more headroom — lean toward eager for frequently used assets to eliminate hitches, but use lazy streaming for very large textures/levels to reduce initial wait.

Choose hybrid: eagerly load gameplay-critical and small assets; lazily load large/rare assets with async streaming and background prefetch to balance latency, memory, and smoothness.

Frame-time targets

• High-end PC (144 FPS): 6.94 ms/frame (~7 ms)
• Console (60 FPS): 16.67 ms/frame (~16.7 ms)
• Mobile (30 FPS): 33.33 ms/frame (~33.3 ms)

CPU / GPU split (practical starting points)

• PC 144: CPU 30% (~2.0 ms), GPU 60% (~4.2 ms), Headroom 10% (~0.7 ms)
• Console 60: CPU 35% (~5.8 ms), GPU 55% (~9.2 ms), Headroom 10% (~1.7 ms)
• Mobile 30: CPU 40% (~13.3 ms), GPU 45% (~15.0 ms), Headroom 15% (~5.0 ms)

Rationale: CPU handles game logic, physics, AI; GPU renders. Mobile gives more CPU time for fallbacks and conservative GPU on weaker tilers; PC favors GPU headroom to enable high visual fidelity.

Headroom for input & OS jitter

• Reserve 8–15% of frame-time for input latency, OS scheduling jitter, driver overhead. Increase to 15% on mobile where OS preemption is common.

Runtime enforcement strategies

• Dynamic quality scaling: reduce shadow resolution, LODs, particle spawn rates when frame-time crosses threshold.
• Adaptive renderer: switch to forward or lower shader permutations on tight budgets.
• Culling & foveated techniques: aggressive frustum/occlusion culling, occluder-aware batching; on mobile use temporal or fixed foveation.
• Budgeted systems: spread expensive tasks over multiple frames (task queue / frame-sliced updates).
• Frame skipping / partial frames: throttle non-essential systems (animations, physics substeps) rather than dropping input/render.
• Monitoring: per-frame telemetry for CPU/GPU timing; simple PID-like controller to adjust quality parameters smoothly.

Example policy

• If GPU > budget two frames in a row: lower shadow cascades or post-process quality by 1 level.
• If CPU > budget: defer non-critical AI ticks and reduce animation blend samples.

These targets are starting points — profile on target hardware and iterate, tuning split and headroom per platform and scene.

Brief overview — causes
Heap fragmentation occurs when many small, variable-lifetime allocations/free patterns leave non-contiguous free blocks so large allocations fail or trigger costly compaction. GPU memory fragments when textures, buffers, and transient render targets of varying sizes are created/destroyed or when resources have different alignment/tiling requirements.

Allocator strategies & how they help

• Pools / Fixed-size object pools

  • Use when many identical-size objects (particles, bullets).
  • Fast O(1) alloc/free, no fragmentation for that size class.
  • Trade-off: internal waste if size mismatch; needs multiple pools for different sizes.

• Arenas (linear/stack)

  • Allocate many short-lived objects en masse and free all at once.
  • Extremely fast, zero fragmentation during use.
  • Trade-off: cannot free individual objects; good for frame scratch or level load.

• Slab / segregated free lists

  • Separate slabs per size class; reduces external fragmentation and fragmentation churn.
  • Good for UI elements, game objects with predictable sizes.
  • Trade-off: some internal fragmentation; complexity grows with number of size classes.

• Buddy allocator

  • Splits memory in power-of-two blocks, good balance of speed and ability to merge free blocks.
  • Trade-off: can waste up to ~50% due to rounding; simpler compaction/merge logic.

• Region-based (memory arenas per subsystem)

  • Assign audio, physics, rendering their own regions so fragmentation isolated per subsystem.
  • Trade-off: harder to rebalance memory at runtime; requires tuning.

• Defragmentation / compaction

  • Moveable allocations with relocation tables for GPU (or CPU) to compact memory.
  • For GPU, requires resource re-creation or support for virtual memory; for CPU, pointer indirection or handle layer.
  • Trade-off: runtime cost and complexity; must pause or incremental compact to avoid hitches.

Platform considerations

• Consoles: more predictable memory; can afford larger pre-allocated pools and offline tuning.
• Mobile: tight memory, power constraints — prefer arenas and small slab pools; avoid runtime compaction.

Practical approach I’d use

• Partition memory by subsystem (regions), combine arenas for transient/frame allocations, slabs/pools for common small objects, and buddy or general-purpose allocator for variable-size long-lived allocations. Add lightweight defragmentation/incremental compaction only where necessary (large GPU heaps).

Clarify goals & constraints

• Target stable FPS per platform (Console/PC: 60 FPS; Mobile: 30–60 FPS), smooth feel, readable UI, minimal visual popping, respect thermal/battery.

Inputs

• Frame-time history buffer (last N frames, e.g., 120 samples) + running mean/std and percentile (95th).
• Platform profile (console/PC/mobile) and user target FPS.
• Thermal state (OK/WARM/HOT) and battery level (percent + power mode).
• GPU/CPU utilization and present resolution scale.
• Scene complexity hints (draw call count, particle counts) if available.

Control algorithms

• Heuristic: step down/up resolution scale by fixed delta (e.g., ±5%) when 95th frame-time > budget or < budget-low for M consecutive windows. Simple, predictable.
• PID controller: input = error = measured frame-time - target frame-time; output = continuous resolution scale adjustment. Use clamping and integral windup guard. Better steady-state, needs tuning per platform.
• Hybrid: PID for fine control + heuristic anti-oscillation (min dwell time, hysteresis).

Min/Max bounds & constraints

• MinScale: platform specific (mobile 50%, console 70%, PC 75%) to preserve legibility.
• MaxScale: 100% (native). Optionally allow >100% on high-end GPUs for better quality.
• Rate limits: max ±10% per second; minimum dwell 0.5–2s.
• Thermal/battery policies: if HOT or battery < 20% and user on battery, cap MaxScale lower (e.g., reduce MaxScale by 15%).

UI & post-processing legibility

• Render UI and critical overlays at a stable independent resolution (render UI at native or a higher fixed scale) or use a two-pass approach: scaled scene render + full-res UI composited.
• Use dynamic sharpening / upscale-aware post-process that adapts strength to scale to reduce blur.
• Ensure font atlas supports hi-DPI; use vector or signed distance field fonts so text remains crisp when scaled.
• Place post-processing after upscaling; avoid expensive full-res effects when downscaling—prefer cheaper, upscale-aware tone mapping, FXAA/sharpen.

Implementation notes (Unity)

• Use Unity’s dynamic resolution APIs (XR/Adaptive Performance packages) where available; fall back to custom CommandBuffer blit with RenderTexture scaled by current scale.
• Keep telemetry for tuning and allow user override & quality presets. Expose smoothing/window size, PID gains, and thermal policies via config.

Trade-offs

• Heuristic: simple, robust; PID: smoother but needs per-platform tuning. Hybrid balances both. Prioritize readability by rendering UI at stable resolution; sacrifice some scene quality before UI fidelity.

Approach summary
On fixed-console hardware you tune for predictable caches and high memory bandwidth. Minimize cache misses by packing hot data contiguously, aligning to cache lines, and using prefetching and pools to avoid fragmentation and pointer-chasing.

SoA vs AoS

• AoS (struct Particle { Vec3 pos; Vec3 vel; float life; ... }) is simple but wastes bandwidth when you only touch one field.
• SoA separates arrays: positions[], velocities[], life[] — ideal for SIMD updates and streaming through cache.
  Example C++ sketch:

struct ParticlesSoA {
  alignas(64) std::vector<Vec3> pos;
  std::vector<Vec3> vel;
  std::vector<float> life;
};

Use AoS when you frequently need all fields for a single entity (collision queries), SoA for bulk physics, rendering, or SIMD.

Alignment & packing

• Align hot arrays to 64-byte cache line boundaries (alignas(64)).
• Pad structs to avoid false sharing between threads.
• Use compiler intrinsics/attributes to control packing only when necessary.

Prefetching

• Software prefetch a few iterations ahead in tight loops (e.g., _mm_prefetch) when access pattern is predictable.
• Example: in particle update loop prefetch pos[i+16] if each element ~ SIMD-friendly.

Memory pools

• Use pools/arenas for short-lived objects (particles, temporary components) to avoid allocator overhead and fragmentation.
• Free lists for fixed-size objects; slab allocator for varying small sizes.
• Combine with SoA by allocating each array from the same pool for locality.

When to apply

• Rendering/animation: SoA + SIMD + aligned buffers.
• AI/Gameplay objects: AoS if per-entity logic touches most fields.
• Networking/replication: compact AoS or packed buffers to reduce bandwidth.
• Systems with frequent allocation: pools/arenas.

Outcome: measurable cache-hit improvements, fewer stalls, and better SIMD utilization on PS5/Xbox Series X.