VR M4: performance -- multiview, shared passes, foveation #1077
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#1072 [Epic] VR support (OpenXR) -- headline feature for 1.6
sky_line/Slipstream
Reference
sky_line/Slipstream#1077
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hard rule (applies to every VR ticket): the non-VR path must not lose quality or FPS. All VR work is optional and only affects the VR path: no new per-frame work, memory, pipelines or device extensions when VR is off; each milestone is gated by a fixed-camera GPU/CPU timer A/B of VR-off against main before it lands.
Per-eye RenderView refactor completed, VK_KHR_multiview for raster passes, fused stereo cull, fixed/eye-tracked foveation via the VRS path, visibility mask, depth layer, async compute re-enabled, GI re-evaluated for VR.
Part of #1072.
Folded into #1075 (2026-10-26): the plan now goes straight to layered stereo (multiview raster + compute over view layers + shared once-per-frame work) instead of a serial render-twice M2 followed by this M4. Foveation / VRS and async re-tuning remain follow-ups under #1075.