RT: rethink the silent auto-off / degrade under low VRAM (confusing to users)

sky_line commented

2026-10-01 19:01:46 +00:00

Owner

Problem

When VRAM runs low, ray tracing silently turns itself off or degrades. Users find this confusing: shadows switch from RT to shadow maps (or objects drop out of RT) with no explanation, and it looks like a rendering bug.

Current mechanisms:

LLCleanRendererVK texture residency (vkgfx/llcleanrenderervk.cpp, the "TEXTURES LAST (#164)" block): under heap pressure, LLCleanRTVK::yieldForPressure() halves the RT memory cap (mPressureCap, floor 256 MB) before the texture mip bias moves. It only logs RT: VRAM pressure -- budget capped at ....
The BLAS budget (RenderVKRTBlasBudgetMB, default 12% of the device budget, 384 MB – 2 GB) plus the pressure cap means geometry that doesn't fit is simply not in the TLAS.
RT sun shadows (RenderVKRTSunShadow = 2) "fall back to shadow maps ... over the RT memory budget". RT projector shadows fall back similarly.
None of this is visible to the user. The settings still read "ray traced".

Goals

Find a better path. Options to evaluate:

Make it visible: when RT degrades or falls back, show a one-time system message or a status indicator ("Ray tracing reduced: low video memory"). Expose the state in the graphics preferences / stats.
Degrade predictably, not all-or-nothing:
- drop far / small objects from the TLAS first (distance / screen-size priority);
- lower RT mask resolution or rays per pixel before disabling RT shadows;
- keep the BLAS set stable to avoid popping.
Decide at the right time: check RT memory needs when the user enables RT (or at startup, from the GPU tier). Refuse with a clear message, rather than enabling it and then quietly undoing it at runtime. Same pattern as the probe-resolution ticket: try-allocate-or-revert plus a message.
Recover: when pressure clears (teleport to a lighter sim, settings lowered), lift mPressureCap back up with hysteresis. Today it only ever ratchets down.
Revisit the priority order between RT and textures (#164) with real data from 8 / 12 GB cards.

Notes

Related: the probe-resolution VRAM OOM ticket filed alongside this one, #164 (8 GB cards starving textures), #159–#163.
Test cards: RTX 3060 12 GB, an 8 GB card, with RT shadows on in a dense sim.

## Problem When VRAM runs low, ray tracing silently **turns itself off or degrades**. Users find this confusing: shadows switch from RT to shadow maps (or objects drop out of RT) with no explanation, and it looks like a rendering bug. Current mechanisms: - `LLCleanRendererVK` texture residency (`vkgfx/llcleanrenderervk.cpp`, the "TEXTURES LAST (#164)" block): under heap pressure, `LLCleanRTVK::yieldForPressure()` halves the RT memory cap (`mPressureCap`, floor 256 MB) before the texture mip bias moves. It only logs `RT: VRAM pressure -- budget capped at ...`. - The BLAS budget (`RenderVKRTBlasBudgetMB`, default 12% of the device budget, 384 MB – 2 GB) plus the pressure cap means geometry that doesn't fit is simply not in the TLAS. - RT sun shadows (`RenderVKRTSunShadow` = 2) "fall back to shadow maps ... over the RT memory budget". RT projector shadows fall back similarly. - None of this is visible to the user. The settings still read "ray traced". ## Goals Find a better path. Options to evaluate: 1. **Make it visible:** when RT degrades or falls back, show a one-time system message or a status indicator ("Ray tracing reduced: low video memory"). Expose the state in the graphics preferences / stats. 2. **Degrade predictably, not all-or-nothing:** - drop far / small objects from the TLAS first (distance / screen-size priority); - lower RT mask resolution or rays per pixel before disabling RT shadows; - keep the BLAS set stable to avoid popping. 3. **Decide at the right time:** check RT memory needs when the user enables RT (or at startup, from the GPU tier). Refuse with a clear message, rather than enabling it and then quietly undoing it at runtime. Same pattern as the probe-resolution ticket: try-allocate-or-revert plus a message. 4. **Recover:** when pressure clears (teleport to a lighter sim, settings lowered), lift `mPressureCap` back up with hysteresis. Today it only ever ratchets down. 5. Revisit the priority order between RT and textures (#164) with real data from 8 / 12 GB cards. ## Notes - Related: the probe-resolution VRAM OOM ticket filed alongside this one, #164 (8 GB cards starving textures), #159–#163. - Test cards: RTX 3060 12 GB, an 8 GB card, with RT shadows on in a dense sim.

sky_line referenced this issue

2026-10-05 03:08:10 +00:00

Epic: RAM/VRAM management -- one budget, tiered texture storage, run on a stated minimum #405

sky_line commented

2026-10-05 03:08:10 +00:00

Author

Owner

Part of #405 (RAM/VRAM management epic).

sky_line added a new dependency

2026-10-05 03:08:10 +00:00

#405 Epic: RAM/VRAM management -- one budget, tiered texture storage, run on a stated minimum

sky_line referenced this issue from a commit

2026-10-05 08:37:46 +00:00

VRAM ladder wired: effective caps, no setting writes under ordinary pressure; hard step last (#405, #227, #226)

sky_line referenced this issue

2026-10-06 11:19:47 +00:00

Advanced graphics: show when ray tracing is inactive (and why) + audit every control's enable/disable rules #483

sky_line commented

2026-10-06 11:19:47 +00:00

Author

Owner

Linked: #483. Ray tracing turned off at runtime leaves the Advanced panel showing "Ray traced" values that aren't in effect, and greys out RT resolution and projector RT with no visible reason. The status line and recovery action in #483 depend on making this auto-off visible and recoverable here.

sky_line added this to the Slipstream project

2026-10-06 15:04:15 +00:00

sky_line added the

status

testing

label

2026-10-09 04:40:37 +00:00

sky_line commented

2026-10-10 04:53:18 +00:00

Author

Owner

Verified 2026-10-10: under VRAM pressure RT degrades softly and reports what it does ('RT memory budget is full: avatars no longer cast ray-traced shadows (scenery still does) until memory frees up'); no silent auto-off and no setting written. Closing.

sky_line

2026-10-10 04:53:19 +00:00