Allocation failures: GPU memory requests retry, then drop -- never crash #697
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.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream#697
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?
Policy (owner, 2026-10-12): a failed allocation is never a crash. Default: keep what we have, retry the request a few frames later (space may free up), then drop that asset/request and log the failure (rate-limited, with what failed, size, and the current RAM/VRAM pressure state). Better a missing texture/mesh than a dead viewer -- and when someone says "things aren't loading", the log tells us it's memory pressure.
Scope (Vulkan / video memory)
stageFor) soft by default; large temporary host-visible buffers get a pre-flight too.ensureCaplast resort), occlusion scratch, particle tables, rig cache, alpha-sort keys.SLVkInjectAllocFail, hard mode) on a teleport loop until no fatal site remains.Fixed in Slipstream 1.3.0 (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0
If you still see this on 1.3.0, reply here and we'll reopen it.