Explore: further texture memory reductions (RAM + VRAM) #263

Closed
opened 2026-10-03 04:18:36 +00:00 by sky_line · 2 comments
Owner

Current numbers (same session):

  • VRAM: textures 7.7 GB of a 15.4 GB process total. Budget 14.2 GB, bias 0; 1,638 textures at full res, 7,200 images; all-full would be 33 GB.
  • RAM: 2.7 GB of CPU texture copies (9,069). The earlier baseline (#159-#164) had 16.7 GB of CPU copies, so most of that is already fixed.

Ideas to evaluate:

  • GPU block compression (BC7 for colour, BC5 for normals, BC4 for masks) transcoded on upload, possibly in compute: 4:1 vs RGBA8, with a large VRAM and bandwidth win. Needs a quality check and transcode cost measurement (CPU vs GPU).
  • Screen-space-driven residency: choose each texture's mip from measured on-screen texel density (GPU feedback, e.g. the tex-demand readback) rather than LL's pixel-area heuristics, so textures that never reach full-res density never get it.
  • Drop CPU copies entirely after upload where nothing needs readback (keep only for sculpts / alpha-mask analysis / picking).
  • Deduplicate identical-content textures (same pixels, different UUID); avatar bakes/skins are common duplicates.
  • Normal / specular map resolution caps relative to diffuse.
  • Sparse/partially-resident textures for very large (2K/4K) images.
  • Tighter residency on 8 GB cards (see #164).

Deliverable: measurements per idea (VRAM saved, quality impact, CPU/GPU cost) on a heavy scene, then a ranked plan.

Current numbers (same session): - VRAM: textures 7.7 GB of a 15.4 GB process total. Budget 14.2 GB, bias 0; 1,638 textures at full res, 7,200 images; all-full would be 33 GB. - RAM: 2.7 GB of CPU texture copies (9,069). The earlier baseline (#159-#164) had 16.7 GB of CPU copies, so most of that is already fixed. Ideas to evaluate: - **GPU block compression** (BC7 for colour, BC5 for normals, BC4 for masks) transcoded on upload, possibly in compute: 4:1 vs RGBA8, with a large VRAM and bandwidth win. Needs a quality check and transcode cost measurement (CPU vs GPU). - **Screen-space-driven residency:** choose each texture's mip from measured on-screen texel density (GPU feedback, e.g. the tex-demand readback) rather than LL's pixel-area heuristics, so textures that never reach full-res density never get it. - **Drop CPU copies entirely** after upload where nothing needs readback (keep only for sculpts / alpha-mask analysis / picking). - **Deduplicate** identical-content textures (same pixels, different UUID); avatar bakes/skins are common duplicates. - **Normal / specular map resolution caps** relative to diffuse. - **Sparse/partially-resident textures** for very large (2K/4K) images. - **Tighter residency on 8 GB cards** (see #164). Deliverable: measurements per idea (VRAM saved, quality impact, CPU/GPU cost) on a heavy scene, then a ranked plan.
Author
Owner

Part of #405 (RAM/VRAM management epic).

Part of #405 (RAM/VRAM management epic).
sky_line added this to the Slipstream project 2026-10-06 15:04:14 +00:00
Author
Owner

Exploration done; the concrete follow-ups are filed and in progress: #614 (texture pool compaction), #615 (render-target aliasing), #616 (compact skinned vertices), #617 (quantized skinned positions, later), #625 (RT shadow mask memory / shimmer). Closing.

Exploration done; the concrete follow-ups are filed and in progress: #614 (texture pool compaction), #615 (render-target aliasing), #616 (compact skinned vertices), #617 (quantized skinned positions, later), #625 (RT shadow mask memory / shimmer). Closing.
sky_line 2026-10-10 04:53:22 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
sky_line/Slipstream#263
No description provided.