VR/XR Performance Deep Dive

The frame budget is half what a flat-3D engineer is used to. At 90 Hz the deadline is 11.1 ms; at 120 Hz it's 8.3 ms; at 72 Hz (Quest default) it's 13.7 ms. Per Meta's PC VR Performance Guidelines, PC-VR Rift target is 90 fps recommended-spec, 45 fps minimum-spec.

And the GPU work doubles. Both eyes have to be rendered, with sufficient overlap that single-pass instanced stereo can amortize work but never eliminate it. Distortion and TimeWarp also reserve roughly 2 ms per frame from the headset compositor — that's gone before your renderer touches anything.

And missed frames are not stutters — they're nausea. When you miss a frame in flat-3D, the image freezes for 16 ms and the player notices. When you miss a frame in VR, the runtime reprojects the previous frame to the new head pose, the player sees ghosting and judder, and they take the headset off. Reprojection can mask geometry costs, but never input-latency costs — and that's the design constraint that shapes everything.

Renderer choice maps to platform tightly:

• Quest (Quest 2/3/Pro): mobile forward + Vulkan. r.MobileHDR=False mandatory for Multi-View.
• PC-VR (Rift, Index, Vive): forward shading for most VR; deferred runs but at significantly higher cost. Lumen/Nanite stereo support exists on UE5 but is experimental, deferred-only, PC-only.
• PSVR2: PS5 deferred renderer with eye-tracked foveated rendering as the headline perf feature.

[/Script/Engine.RendererSettings]
r.MobileHDR=False                      ; required for MultiView
r.Mobile.AntiAliasing=3                ; MSAA
r.MobileMSAA=4                         ; 4x sample count
vr.MobileMultiView=1                   ; tiled GPU stereo
r.Mobile.PackLightGridLightDataToUBO.Enable=1
r.Forward.NoLightGridIfNoLightOpt=1    ; saves ~0.14ms when no dynamic lights

Both vr.InstancedStereo and vr.MobileMultiView are ECVF_ReadOnly — they must live in DefaultEngine.ini and be set before shader compilation. Setting them at runtime silently no-ops.

Both reduce per-eye CPU cost by submitting one draw call that produces two views. The difference is implementation:

• Instanced Stereo Rendering (ISR): vr.InstancedStereo=1. Single instanced draw, vertex shader writes both eye positions via SV_RenderTargetArrayIndex. Runs on desktop GPUs.
• Mobile Multi-View (MMV): vr.MobileMultiView=1. The same conceptual savings, but uses the tile-based GPU's hardware-accelerated multi-view extension. Runs on Quest/mobile-XR Vulkan only.

UE 5.2 tuned the ISR/MMV pass and reported ~5% GPU win on Quest 2 (per UE 5.2 release notes). They don't combine — one or the other.

MSAA is the right answer for VR on tile-based mobile GPUs. The tile buffer natively supports multiple samples per pixel, so 4× MSAA on Quest's Adreno is roughly free in bandwidth and trivially cheap in fragment cost. Avoid TAA and FXAA in VR — both produce visible smear under head motion and sub-pixel aliasing is amplified by the lens-warp distortion.

For PC-VR with a forward shading path, r.MSAACount=4 (or 8 on flagship GPUs) is the canonical setting. Deferred-on-PC-VR cannot use MSAA the same way, which is part of why forward shading is preferred for VR even on hardware where deferred is normally faster.

Foveated rendering reduces shading cost in the periphery, where the lens optics blur detail anyway. Two flavors:

Fixed Foveated Rendering (FFR). Fixed-position quality reduction toward edges. Per Meta's FFR docs: pixel-bound app savings of ~6.5% (Low), ~11.5% (Medium), ~21% (High) on Quest. Available on all Quest and Quest-class mobile XR.

Eye-Tracked Foveated Rendering (ETFR). Quality is centered on the user's actual gaze point. ETFR has higher GPU savings on average than FFR across all levels (per Meta). Quest Pro supports ETFR; Quest 3/3S do not. PSVR2 has eye tracking and supports an equivalent feature: PSVR2 documentation cites GPU frame time up to 3.6× faster with eye-tracked foveated, 2.5× faster without (Sony GDC).

Foveated levels are runtime-toggleable on Quest:

// 0=Off 1=Low 2=Medium 3=High 4=HighTop
UOculusXRFunctionLibrary::SetFoveatedRenderingLevel(level, isDynamic);

// ADB runtime override (debug only):
adb shell setprop debug.oculus.foveation.level 3
adb shell setprop debug.oculus.foveation.dynamic 1

Dynamic FFR adapts level based on GPU pressure. On Quest, prefer Dynamic FFR over Dynamic Resolution — FFR keeps central pixels sharp; DR scales the whole image down.

VR cares about motion-to-photon (MTP) latency — how long between the headset moving and the player seeing the new frame. Long MTP = swimminess and discomfort. UE's primary MTP-saving tool on Quest is Late Latching, which substitutes a fresher head/controller pose into the rendered frame just before submission, removing up to one frame of input latency.

Per Meta's Late Latching docs: example reductions of 45 ms predicted-render-delay (PRD) down to 35 ms.

Late Latching has hard incompatibilities:

• Multi-View + Vulkan mandatory — not available on OpenGL ES or non-MMV builds.
• UE4 conflict: occlusion culling must be off.
• UE5 conflict: r.Vulkan.UseEmulatedUBs must be off (mutually exclusive optimizations).

Phase Sync was deprecated in UE5; UE4-era advice citing it no longer applies. Late Latching is the supported successor.

Async TimeWarp (ATW) is the runtime's safety net — if your app drops a frame, the runtime reprojects the previous frame to the new head pose. Automatic. Free.

Application SpaceWarp (ASW) is a different beast: the app renders at half the headset refresh rate (e.g., 36 fps on a 72 Hz Quest), and the runtime synthesizes the intermediate frames using motion vectors. Per Meta's ASW docs, ASW provides "up to 70% additional compute" headroom — effectively doubling your GPU budget at the cost of motion-vector authoring requirements.

r.Mobile.Oculus.SpaceWarp.Enable=True

Quest has a CPU/GPU level system — the runtime selects performance levels based on thermal headroom. Apps can request boost levels short-term, but boost is rate-limited to 45 second windows, totaling no more than 20% of runtime (per Meta's Quest Boost docs). Using boost as a steady-state crutch produces a regression in the live build.

Boost gains by device:

Per Meta's PC and Quest performance guides: game-thread time should stay under 2–3 ms per system, and any single function pinning over 2 ms is flag-worthy. Draw-call budgets: Quest 3 100–500 per frame, PC-VR 500–1000. Triangle budgets post-cull: Quest 3 100k–250k, PC-VR 1–2 M.

UE 5.5 renamed vr.PixelDensity to xr.SecondaryScreenPercentage.HMDRenderTarget. Code referencing the old CVar silently no-ops on 5.5+ — this is one of the most common gotchas after upgrading.

Oculus Dynamic Resolution clamps the eye-buffer scale to 0.7×–1.3× of default (per Meta's DynRes docs). The defaults:

r.Oculus.DynamicResolution.PixelDensity=0       ; 0 = runtime control
r.Oculus.DynamicResolution.PixelDensityMin=0.7
r.Oculus.DynamicResolution.PixelDensityMax=1.3

GPU level 5 on Quest 3 requires Dynamic Resolution enabled — otherwise thermal throttle drops you mid-session with no recovery path.

Per Epic's Nanite and Lumen for XR page: stereo support is experimental, PC-only, deferred renderer only, DX12 SM6 required. Not viable on Quest.

VSM works on PC-VR with reduced page pool / shadow quality, but cost scales with view count — instanced stereo halves the cost vs naive multi-pass. Most shipped UE5 PC-VR titles ship with conventional CSM rather than VSM.

For Quest, the realistic toolset is identical to mobile — one stationary directional + CSM + baked GI + DFAO sky. Translucency is the #1 fragment-bound culprit on tiled GPUs; particle systems with overlapping translucent quads are the easiest perf trap to fall into.

The summary that should live in your project's design doc:

PerfGuard can lock these as platform-aware regression budgets — per-eye GPU time with a 9 ms ceiling at 90 Hz, draw-call gates per platform, FFR/ETFR config detection (so a "now-FFR-Off" regression surfaces as a config drift not a perf regression), and a frame-pacing histogram with p99.9 > 1.0×refresh-period as a "reprojection imminent" warning.

• Mobile Performance — the mobile-side overlap; Quest is a mobile target with a HMD attached.
• Upscaler Tuning — why TAA/TSR don't ship in VR.
• Common UE Performance Gotchas — same gotchas, half the budget.