GPU texture disk cache: save partial mip chains instead of refusing them (small textures reload slowly on prefer-disk machines) #991

New issue

Closed

opened 2026-10-23 19:18:24 +00:00 by sky_line · 1 comment

sky_line commented

2026-10-23 19:18:24 +00:00

Owner

GPU-ready texture captures that aren't a full mip chain are never written to the GPU-ready disk cache (LLGpuTexStore::write: "GPU-ready capture of ... is not a full mip chain (128x128, 8 levels ...): not written").

Why it matters

Seen in #977 (RTX 3050 Laptop, 16 GB RAM): small textures (small prims, timers, car parts) stay low-res or don't load until the camera is very close.

With less than SlipstreamTextureDiskBelowRAMGB (24 GB) of RAM, texture memory mode Auto behaves as prefer disk: no decoded copies are kept in RAM, and textures reload from the GPU-ready disk cache.
A texture whose capture was refused has no disk copy, so after every eviction it goes back through the full fetch-and-decode path.
Under RAM pressure the memory governor cuts the decode budget (from 502 to about 96 MB in that log), so these small textures wait behind everything else.

Wanted

Always save what we have: write partial mip chains (the levels we hold) to the disk cache, so a later reload never redoes work we already did. Upgrade the entry when more levels arrive. Never downgrade a fuller entry with a smaller one.
Prefer the full chain as quickly as possible: when a capture is partial, request or complete the missing levels promptly (e.g. generate the smaller mips on the GPU, or fetch the higher discard), so the cached entry becomes a full chain soon.
Readers must handle a partial entry: use it as an immediate low-res result, and still request the rest.
Keep the cache bounded (existing budget, LRU), and keep entry validity (asset id plus format / compression version) intact.

GPU-ready texture captures that aren't a full mip chain are never written to the GPU-ready disk cache (`LLGpuTexStore::write`: "GPU-ready capture of ... is not a full mip chain (128x128, 8 levels ...): not written"). ## Why it matters Seen in #977 (RTX 3050 Laptop, 16 GB RAM): small textures (small prims, timers, car parts) stay low-res or don't load until the camera is very close. - With less than `SlipstreamTextureDiskBelowRAMGB` (24 GB) of RAM, texture memory mode Auto behaves as **prefer disk**: no decoded copies are kept in RAM, and textures reload from the GPU-ready disk cache. - A texture whose capture was refused has no disk copy, so after every eviction it goes back through the full fetch-and-decode path. - Under RAM pressure the memory governor cuts the decode budget (from 502 to about 96 MB in that log), so these small textures wait behind everything else. ## Wanted - **Always save what we have:** write partial mip chains (the levels we hold) to the disk cache, so a later reload never redoes work we already did. Upgrade the entry when more levels arrive. Never downgrade a fuller entry with a smaller one. - **Prefer the full chain as quickly as possible:** when a capture is partial, request or complete the missing levels promptly (e.g. generate the smaller mips on the GPU, or fetch the higher discard), so the cached entry becomes a full chain soon. - Readers must handle a partial entry: use it as an immediate low-res result, and still request the rest. - Keep the cache bounded (existing budget, LRU), and keep entry validity (asset id plus format / compression version) intact.

sky_line added the

perf

bug

labels

2026-10-23 19:18:24 +00:00

sky_line added this to the Slipstream project

2026-10-23 19:18:24 +00:00

sky_line referenced this issue from a commit

2026-10-23 20:58:20 +00:00

#991: GPU texture disk cache -- partial chains upgrade in place (the "not a full mip chain" refusal)

sky_line referenced this issue from a commit

2026-10-23 20:58:20 +00:00