GPU-ready texture cache: store block-compressed textures on disk (skip J2C decode + encode on reload)

sky_line commented

2026-10-03 23:47:08 +00:00

Owner

Cache GPU-ready block-compressed texture data on disk, so textures seen before skip the JPEG2000 decode and the GPU encode on later loads.

Why

Today every texture goes: download or LL disk cache (J2C) → CPU JPEG2000 decode (OpenJPEG; the most expensive CPU work in the viewer, which saturates the decode threads at login and teleports) → RGBA upload → GPU BC encode (#263 texture compression).

With a BC cache, a texture already seen loads from disk straight into the GPU: no J2C decode, no encode. Expected wins:

Much faster texture loading when returning to places you visit often.
Lower RAM peak at login and teleport (#262): decoded RGBA buffers in flight are a big part of that spike.
Less CPU during loading: decode threads freed for content you haven't seen.

Design sketch

Key: texture UUID + format (BC1/BC3/BC5/BC7 variant, sRGB/UNORM) + encoder version + resident mip level. SL assets are immutable, so entries never go stale except across encoder versions, which are ignored and age out.
Value: the BC blocks for the resident mip chain, plus the adaptive and constant-colour flags (see the adaptive decision cache from the texture-compression work).
Write path: after a GPU encode, an async readback of the BC blocks (a staging ring, not on the main thread), then an async disk write. Never stall a frame.
Read path: in the fetch/residency pipeline, check the BC cache before requesting a J2C decode. On a hit, upload the blocks directly into the BC image at that level. If the texture needs a higher detail level than cached, fall back to the normal J2C decode and cache the new level.
Storage:
- Its own directory and index in the cache dir, with an LRU byte budget (setting, default about 2-4 GB).
- Separate from LL's texture cache, which stays the source of truth.
- Atomic writes, a corruption-tolerant index (bad entries are dropped).
- Wiped by Clear Cache.
Format interaction: entries are only valid for the current compression level and format. Switching level means re-encoding as now (and caching the new format); old-format entries age out.
Memory rule: bounded index in RAM, bounded staging, no unbounded growth.

Costs and risks

Disk usage: BC7 is 8 bpp, often 3-5x larger on disk than J2C. Needs a clear budget setting and a size readout.
Partial-level semantics vs J2C's progressive discard levels: the cache stores fixed levels.
New plumbing: async readback, disk I/O thread, index.
Verify: that loading compressed blocks from disk is faster end-to-end than J2C decode + GPU encode on typical SSDs and HDDs.

Measure

Login and teleport time to "textures settled" and the peak RSS (#262), first visit vs return visit, with the cache on vs off, at a heavy region.

Cache **GPU-ready block-compressed texture data** on disk, so textures seen before skip the JPEG2000 decode and the GPU encode on later loads. ## Why Today every texture goes: download or LL disk cache (J2C) → **CPU JPEG2000 decode** (OpenJPEG; the most expensive CPU work in the viewer, which saturates the decode threads at login and teleports) → RGBA upload → GPU BC encode (#263 texture compression). With a BC cache, a texture already seen loads from disk straight into the GPU: no J2C decode, no encode. Expected wins: - **Much faster texture loading** when returning to places you visit often. - **Lower RAM peak at login and teleport (#262):** decoded RGBA buffers in flight are a big part of that spike. - **Less CPU during loading:** decode threads freed for content you haven't seen. ## Design sketch - **Key:** texture UUID + format (BC1/BC3/BC5/BC7 variant, sRGB/UNORM) + encoder version + resident mip level. SL assets are immutable, so entries never go stale except across encoder versions, which are ignored and age out. - **Value:** the BC blocks for the resident mip chain, plus the adaptive and constant-colour flags (see the adaptive decision cache from the texture-compression work). - **Write path:** after a GPU encode, an async readback of the BC blocks (a staging ring, not on the main thread), then an async disk write. Never stall a frame. - **Read path:** in the fetch/residency pipeline, check the BC cache before requesting a J2C decode. On a hit, upload the blocks directly into the BC image at that level. If the texture needs a *higher* detail level than cached, fall back to the normal J2C decode and cache the new level. - **Storage:** - Its own directory and index in the cache dir, with an LRU byte budget (setting, default about 2-4 GB). - Separate from LL's texture cache, which stays the source of truth. - Atomic writes, a corruption-tolerant index (bad entries are dropped). - Wiped by Clear Cache. - **Format interaction:** entries are only valid for the current compression level and format. Switching level means re-encoding as now (and caching the new format); old-format entries age out. - **Memory rule:** bounded index in RAM, bounded staging, no unbounded growth. ## Costs and risks - **Disk usage:** BC7 is 8 bpp, often 3-5x larger on disk than J2C. Needs a clear budget setting and a size readout. - **Partial-level semantics vs J2C's progressive discard levels:** the cache stores fixed levels. - **New plumbing:** async readback, disk I/O thread, index. - **Verify:** that loading compressed blocks from disk is faster end-to-end than J2C decode + GPU encode on typical SSDs and HDDs. ## Measure Login and teleport time to "textures settled" and the peak RSS (#262), first visit vs return visit, with the cache on vs off, at a heavy region.

sky_line added the

perf

rendering

labels

2026-10-03 23:47:08 +00:00

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

2026-10-05 03:23:41 +00:00

Stretch: run Slipstream in 2 GB of VRAM (iGPUs / very low spec) -- define a very-low tier and the features it cuts #408