Cache store: GPU-ready textures as per-level records (read only the mips a request needs) #865

New issue

Closed

opened 2026-10-19 09:55:27 +00:00 by sky_line · 1 comment

sky_line commented

2026-10-19 09:55:27 +00:00

Owner

Follow-up to #715. GPU-ready (GPUTEX) records hold the whole mip chain as one zstd frame (level 0 first, llgputexrecord.h), so every read loads and decompresses the full chain. zstd can't seek inside a frame, and the store's readRange only avoids decompression for uncompressed kinds.

Data (read-use metrics, first 10 min of a fully migrated session)

8,332 GPU-ready reads. Only 23.3% needed the full chain.
Levels skipped below the top: 0 / 1 / 2 / 3+ = 1,940 / 1,565 / 1,670 / 3,157 reads.
1,122 MB needed of 7,164 MB read (15.7%). About 6× more bytes are read and decompressed than are used.

Plan

New layout: one record for the small tail (levels <= 256 px, tunable) plus one record per larger level. Use spare key variant bits (above the mask/role bits) for the level. Each record keeps the store's own integrity checks, and a request reads only tail + the levels it needs.
No migration pass. Meta version 2 marks the new layout.
- A v1 (whole-chain) record that gets read is already fully decoded. The background writer rewrites it as v2 (encode cost only, throttled with the same never-lag limits as the migrations), then drops the v1 record.
- New writes are v2. Unread v1 records age out under the budget.
Upgrade reads (resident tail -> higher level) fetch only the missing levels.
Keep read-use metrics. Success = needed/read bytes near 1 and read MB/s down by roughly the same factor.

Acceptance

Session metrics show needed/read > 80% after the rewrite has caught up, and lower GPU-ready read MB/s and decode time at the same scene.
Corruption in one level record drops only that level. The requester falls back to J2C for that texture.
Mixed v1/v2 store works, and interrupting the rewrite is safe.

Follow-up to #715. GPU-ready (GPUTEX) records hold the whole mip chain as one zstd frame (level 0 first, `llgputexrecord.h`), so every read loads and decompresses the full chain. zstd can't seek inside a frame, and the store's `readRange` only avoids decompression for uncompressed kinds. ## Data (read-use metrics, first 10 min of a fully migrated session) - 8,332 GPU-ready reads. Only **23.3%** needed the full chain. - Levels skipped below the top: 0 / 1 / 2 / 3+ = 1,940 / 1,565 / 1,670 / 3,157 reads. - **1,122 MB needed of 7,164 MB read (15.7%).** About 6× more bytes are read and decompressed than are used. ## Plan - New layout: one record for the small tail (levels <= 256 px, tunable) plus one record per larger level. Use spare key variant bits (above the mask/role bits) for the level. Each record keeps the store's own integrity checks, and a request reads only tail + the levels it needs. - **No migration pass.** Meta version 2 marks the new layout. - A v1 (whole-chain) record that gets read is already fully decoded. The background writer rewrites it as v2 (encode cost only, throttled with the same never-lag limits as the migrations), then drops the v1 record. - New writes are v2. Unread v1 records age out under the budget. - Upgrade reads (resident tail -> higher level) fetch only the missing levels. - Keep read-use metrics. Success = needed/read bytes near 1 and read MB/s down by roughly the same factor. ## Acceptance - Session metrics show needed/read > 80% after the rewrite has caught up, and lower GPU-ready read MB/s and decode time at the same scene. - Corruption in one level record drops only that level. The requester falls back to J2C for that texture. - Mixed v1/v2 store works, and interrupting the rewrite is safe.

sky_line added the

perf

label

2026-10-19 09:55:27 +00:00

sky_line added this to the Slipstream project

2026-10-19 09:55:27 +00:00

sky_line referenced this issue from a commit

2026-10-19 11:20:27 +00:00

GPU-ready textures as per-level store records (#865)

sky_line referenced this issue from a commit

2026-10-19 11:20:27 +00:00

GPU-ready chain lookup without heap allocations (#865)