VR Performance Budget

Required engineering vr_performance_budget

Agent Prompt Snippet

Ensure the project has a VR performance budget defining frame rate targets, draw call limits, memory ceilings, and rendering constraints.

Purpose

VR is the least forgiving runtime environment in consumer software. A dropped frame in a web app is a flicker; a dropped frame in VR is nausea. At 90 Hz the GPU and CPU share an 11.1 ms window to produce each frame. At 120 Hz that shrinks to 8.3 ms. Miss that window consistently and the vestibular–visual conflict triggers motion sickness — the one bug that makes players uninstall immediately.

A VR performance budget is the document that turns those millisecond constraints into actionable engineering limits. It defines exactly how the per-frame time is allocated between CPU simulation, GPU rendering, audio processing, and OS overhead. It sets hard ceilings on draw calls, triangle counts, texture memory, and shader complexity — broken out per target headset. A Quest 3 running a Snapdragon XR2 Gen 2 has a fundamentally different budget than a PC tethered to an RTX 4080.

The budget also accounts for thermal throttling on standalone headsets, where sustained GPU load causes the chipset to clock down after minutes of peak usage, silently eroding your frame margin. It specifies how much headroom reprojection techniques like Asynchronous SpaceWarp (ASW) or Application SpaceWarp buy you — and makes clear that reprojection is a safety net for transient spikes, never a design target.

Without this document, artists create environments that look stunning in the editor and stutter on hardware. Programmers optimize the wrong subsystem. QA reports “it feels bad” without a measurable threshold to triage against. The performance budget gives every discipline a shared ceiling they can plan around before a single asset is committed.

Who needs this document

Persona	Why they need it	How they use it
Sam (solo indie developer)	Sam is building for Quest and cannot afford late-stage rewrites when scenes exceed mobile GPU limits.	Uses the budget to set per-scene draw call and triangle caps before modeling begins, checking against Oculus performance metrics during weekly profiling runs.
Claude Code (AI coding agent)	Generates rendering code, shader variants, and LOD configurations that must respect hard frame-time constraints.	References the budget before writing draw calls or allocating render targets, ensuring generated code stays within the documented GPU time slice and memory ceiling for each target platform.
Priya (QA lead)	Needs objective pass/fail criteria for performance testing across multiple headsets and scenes.	Builds automated profiling gates in CI that fail the build when any scene exceeds the budgeted frame time, draw call count, or texture memory allocation.
DevOps (build & release engineer)	Must configure profiling tools, headset farm hardware, and CI pipelines to enforce the budget automatically.	Sets up OVR Metrics Tool or RenderDoc capture steps in the build pipeline, compares results against budget thresholds, and alerts the team when regressions land on main.

What separates a good version from a bad one

Criterion 1: Platform-specific numeric limits

A performance budget must contain actual numbers tied to actual hardware.

✓ “Quest 3: 11.1 ms frame budget — 7.0 ms GPU, 3.0 ms CPU, 1.1 ms OS/compositor. Max 150 draw calls, 750K triangles visible, 1.5 GB texture memory.”

✗ “Keep frame times low and draw calls reasonable for mobile.”

Vague guidance cannot be enforced by tooling or checked in review. Every target headset needs its own column with concrete ceilings for GPU time, CPU time, draw calls, triangle count, texture memory, and audio DSP allocation.

Criterion 2: Budget allocation per subsystem

The frame-time ceiling must be decomposed into slices that individual teams own.

✓ “Of the 7.0 ms GPU budget: 3.5 ms opaque geometry, 1.5 ms transparent/particle, 1.0 ms post-processing, 0.5 ms foveated rendering inner ring, 0.5 ms UI overlay.”

✗ “The GPU budget is 7 ms. Don’t exceed it.”

Without sub-allocations, no one knows whether their subsystem is the bottleneck. The rendering programmer assumes particles are cheap; the VFX artist assumes geometry is the problem. Sub-budgets create accountability and make profiling data actionable.

Criterion 3: Thermal and sustained-load profiles

Standalone headsets throttle under sustained load. A budget that only targets peak performance will fail five minutes into gameplay.

✓ “Quest 3 sustained thermal profile: GPU clocks reduce to 80% after 8 minutes at peak. Budget assumes sustained clocks — peak headroom reserved for scene transitions only. Profiling runs must last ≥ 15 minutes.”

✗ “Test on Quest hardware before release.”

Thermal throttling is invisible in short profiling sessions. The budget must specify minimum profiling durations and whether targets assume peak or sustained clock speeds.

Criterion 4: Foveated rendering and reprojection policy

These techniques change the effective budget but introduce tradeoffs that must be documented.

✓ “Fixed foveated rendering Level 3 enabled on Quest — saves ~25% fragment shading. ASW activates below 72 fps as a fallback; any scene that relies on ASW to hit 72 fps is a P0 bug.”

✗ “Enable foveated rendering for performance.”

The budget must state which foveated rendering level is assumed in the baseline numbers and make explicit that reprojection is a failure mode, not a feature. Scenes designed to run at 45 fps with ASW doubling to 90 fps produce visible artifacts on fast head rotation and controller tracking.

Common mistakes

Treating reprojection as free frames. ASW and similar techniques synthesize intermediate frames by warping the previous frame. This works for slow head movement but introduces shimmer on high-contrast edges, smears particle effects, and adds 1–2 ms of latency. Budgets that target 45 fps “because ASW handles the rest” ship products that feel wrong even if the frame counter looks fine.

Ignoring audio in the frame budget. Spatial audio with HRTF processing on 32+ simultaneous sources can consume 1–2 ms of CPU time per frame. On standalone headsets sharing a single SoC, that directly competes with gameplay simulation. The budget must include an audio time slice or risk mysterious CPU spikes during combat scenes.

One budget for all scenes. A menu scene, an open-world vista, and a dense interior have radically different performance profiles. Effective budgets define per-scene or per-zone allocations, with a “worst-case reference scene” that CI profiling runs against. A single global budget either constrains simple scenes unnecessarily or permits complex scenes to overshoot.

Profiling only in the editor. Engine editors render with different code paths, debug overlays, and often on the developer’s high-end PC. The budget must specify that profiling happens on target hardware with release builds. CI should automate this via headset device farms or at minimum via GPU-accurate emulation.

How to use this document

When to create it

Create the performance budget during pre-production, before artists begin building final environments or programmers commit to a rendering pipeline. The budget should exist before the first shader is written. Update it at each milestone when target hardware changes or new rendering features (ray tracing, dynamic GI) are added to the pipeline.

Who owns it

The technical director or lead rendering programmer owns the budget. They set the top-level frame-time allocation, negotiate sub-budgets with art, audio, and gameplay leads, and arbitrate when a subsystem requests more headroom. On smaller teams, whoever profiles most frequently owns it by default.

How AI agents should reference it

get_standard_docs(type="video_game", features=["vr"])
→ vr_performance_budget in documents[]

AI agents generating rendering code, LOD configurations, shader variants, or scene loading logic should retrieve the performance budget first and validate that their output respects the documented limits. When proposing a new particle system or post-processing pass, cite the relevant GPU sub-budget and show that the addition fits within the remaining allocation.

How it connects to other documents

The VR Interaction Design spec defines what the player experiences; the performance budget defines what the hardware can deliver. Interaction latency targets (controller-to-photon < 20 ms) depend on hitting frame-time budgets consistently. The Performance Budget (non-VR) may exist as a superset for cross-platform titles — the VR budget adds headset-specific constraints on top. The Spatial Audio Spec allocates HRTF processing time that must fit within the CPU slice defined here. The Testing Strategy should reference budget thresholds as automated CI gates, failing builds that regress beyond documented limits.