Virtual / sparse texturing: fixed-size texture pages (sparse binding or software VT) #586

New issue

Open

opened 2026-10-09 03:38:06 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-09 03:38:06 +00:00

Owner

Long-term VRAM architecture (later, not now). Replace per-texture residency with fixed-size pages, using Vulkan sparse binding or a software page table with page-cache textures.

Why

Every resident unit is the same size, so the pool cannot fragment. That removes the partial-block / defrag problem that per-texture pooling has (see the size-class pool work).
Residency becomes per tile: only the tiles and mips actually sampled are resident. SL scenes have thousands of unique textures, many seen at small sizes or only partly, so this is far more efficient than whole-texture or whole-mip residency.
One large tile pool means a handful of allocations total, with no per-texture driver calls.

Shape

Pick a tile size: 64 KiB pages (VK_IMAGE_CREATE_SPARSE_RESIDENCY, standard sparse image block shapes) or 128x128 texel tiles in a software VT.
Feedback pass: the GPU writes requested (texture, mip, tile) ids, the CPU or a compute pass dedups them and requests the missing tiles.
Tile streaming: decode/transcode per tile (J2C is region-decodable at some cost), upload into pool pages, then update the page table / sparse bindings.
Shaders: bindless sampling goes through the page table, or uses sparse residency queries with a fallback to a coarser resident mip.
Interactions: BC compression per tile, RT hit shaders (need a resident fallback mip), the VRAM ladder (becomes a page budget), probes and snapshots.

Risks

Large rewrite of texture residency.
Sparse binding support and performance vary by vendor; queue vkQueueBindSparse cost.
Page-table indirection cost per sample.
J2C tile decode efficiency.

Roadmap item. Revisit after size-class texture pools have shipped and been measured.

**Long-term VRAM architecture (later, not now).** Replace per-texture residency with fixed-size pages, using Vulkan sparse binding or a software page table with page-cache textures. ## Why - Every resident unit is the same size, so the pool cannot fragment. That removes the partial-block / defrag problem that per-texture pooling has (see the size-class pool work). - Residency becomes **per tile**: only the tiles and mips actually sampled are resident. SL scenes have thousands of unique textures, many seen at small sizes or only partly, so this is far more efficient than whole-texture or whole-mip residency. - One large tile pool means a handful of allocations total, with no per-texture driver calls. ## Shape - Pick a tile size: 64 KiB pages (`VK_IMAGE_CREATE_SPARSE_RESIDENCY`, standard sparse image block shapes) or 128x128 texel tiles in a software VT. - **Feedback pass:** the GPU writes requested (texture, mip, tile) ids, the CPU or a compute pass dedups them and requests the missing tiles. - **Tile streaming:** decode/transcode per tile (J2C is region-decodable at some cost), upload into pool pages, then update the page table / sparse bindings. - **Shaders:** bindless sampling goes through the page table, or uses sparse residency queries with a fallback to a coarser resident mip. - **Interactions:** BC compression per tile, RT hit shaders (need a resident fallback mip), the VRAM ladder (becomes a page budget), probes and snapshots. ## Risks - Large rewrite of texture residency. - Sparse binding support and performance vary by vendor; queue `vkQueueBindSparse` cost. - Page-table indirection cost per sample. - J2C tile decode efficiency. Roadmap item. Revisit after size-class texture pools have shipped and been measured.

sky_line added the

labels

2026-10-09 03:38:06 +00:00

sky_line added this to the Slipstream project

2026-10-09 03:38:06 +00:00

sky_line added

priority

low