sky_line/Slipstream

Fork 1

RAM: 16.7 GB of CPU texture copies kept after GPU upload #159

New issue

Closed

opened 2026-09-29 05:49:02 +00:00 by sky_line · 2 comments

sky_line commented

2026-09-29 05:49:02 +00:00

Owner

Users report excessive RAM use. A busy two-sim view (2026-09-29, ~45 avatars) measured 28.3 GB RSS (26.2 GB anonymous). The viewer's own accounting (VKMem log line, [cpu tex ...]):

cpu tex 16742MB 22839 copies

That's LLImageGL::sVKCpuBytes: pixel copies retained so the Vulkan path can (re)upload textures. It's more than half the process, while the GPU holds only 3.4 GB of textures at the residency it actually uses.

Direction (standard engine practice)

Once a texture's resident GPU image is uploaded, drop the CPU pixel copy.
When a sharper mip is needed later (residency upgrade) or the image must be rebuilt (eviction / device loss), re-decode from the local texture cache. The J2C bytes are already on disk; LL's decode pipeline can produce any discard level.
Keep a CPU copy only while an upload is pending, and for images that need CPU access: media, UI / local bitmaps, the eyedropper, anything reading pixels back.
Bound whatever remains with a budget (LRU of CPU copies, e.g. RenderVKCpuTexBudgetMB), rather than retaining every texture ever decoded.

Check

cpu tex in the VKMem line should fall from 16.7 GB to a small working set; RSS should drop by roughly the same.
Residency upgrades / downgrades still work (no stuck-blurry textures, no magenta): they now wait on a re-decode instead of a memcpy, so measure upgrade latency.
Local textures (#109 / Local Assets) and media keep working.

Refs #157 (perf/memory audit).

Users report excessive RAM use. A busy two-sim view (2026-09-29, ~45 avatars) measured **28.3 GB RSS** (26.2 GB anonymous). The viewer's own accounting (`VKMem` log line, `[cpu tex ...]`): ``` cpu tex 16742MB 22839 copies ``` That's `LLImageGL::sVKCpuBytes`: pixel copies retained so the Vulkan path can (re)upload textures. It's more than half the process, while the GPU holds only 3.4 GB of textures at the residency it actually uses. ## Direction (standard engine practice) - Once a texture's resident GPU image is uploaded, **drop the CPU pixel copy**. - When a sharper mip is needed later (residency upgrade) or the image must be rebuilt (eviction / device loss), **re-decode from the local texture cache**. The J2C bytes are already on disk; LL's decode pipeline can produce any discard level. - Keep a CPU copy only while an upload is pending, and for images that need CPU access: media, UI / local bitmaps, the eyedropper, anything reading pixels back. - Bound whatever remains with a budget (LRU of CPU copies, e.g. `RenderVKCpuTexBudgetMB`), rather than retaining every texture ever decoded. ## Check - `cpu tex` in the VKMem line should fall from 16.7 GB to a small working set; RSS should drop by roughly the same. - Residency upgrades / downgrades still work (no stuck-blurry textures, no magenta): they now wait on a re-decode instead of a memcpy, so measure upgrade latency. - Local textures (#109 / Local Assets) and media keep working. Refs #157 (perf/memory audit).

sky_line referenced this issue

2026-09-29 05:50:31 +00:00

Textures on avatars are slow to load/Don't load at all/Low in super low Res #145

sky_line referenced this issue from a commit

2026-09-29 07:48:13 +00:00

Texture RAM: thumbnail CPU copies the GPU no longer needs; start stuck fetches

sky_line referenced this issue

2026-09-29 08:34:19 +00:00

World Map: sims (region tiles) not drawing in the map window #166

sky_line referenced this issue

2026-10-02 10:58:14 +00:00

VRAM footprint: 7.5 GB on a 12 GB card in a moderate sim — investigate leak / over-allocation #244

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 from a commit

2026-10-05 08:37:46 +00:00

Texture RAM tiers: governor-driven tier-1 policy, Prefer disk cache mode

sky_line referenced this issue from a commit

2026-10-05 08:37:46 +00:00

VK textures: serve textures from the GPU-ready disk cache (no full decode, no encode)

sky_line referenced this issue

2026-10-05 11:45:07 +00:00

Feature: colour palette generator (colour-theory sets) with a world pick that samples the material colour, not the post-processed pixel #431

sky_line added this to the Slipstream project

2026-10-06 15:04:15 +00:00

sky_line commented

2026-10-07 22:00:59 +00:00

Author

Owner

Ticket audit 2026-10-07: done and shipped in 1.0.0 Beta 10. CPU texture copies cut to thumbnails after upload, governor-trimmed, tiered, and served from the GPU-ready disk cache (475bfa8d4f, 0e64a5c9c1, d18a2f978f, 3b69be27c5, 2e46bbcecd). If you still see the problem on the current beta, please reopen or file a new report.

Ticket audit 2026-10-07: done and shipped in **1.0.0 Beta 10**. CPU texture copies cut to thumbnails after upload, governor-trimmed, tiered, and served from the GPU-ready disk cache (475bfa8d4f, 0e64a5c9c1, d18a2f978f, 3b69be27c5, 2e46bbcecd). If you still see the problem on the current beta, please reopen or file a new report.

sky_line closed this issue

2026-10-07 22:00:59 +00:00

sky_line referenced this issue

2026-10-10 04:53:22 +00:00

Epic: RAM/VRAM management -- one budget, tiered texture storage, run on a stated minimum #405

sky_line referenced this issue

2026-10-10 09:31:34 +00:00

Explore: GPU (Vulkan compute) JPEG2000 decoder -- fetched J2C straight into the bindless texture store #634

sky_line referenced this issue

2026-10-10 10:36:43 +00:00

RAM: retained CPU texture copies overshoot the allowance on big-region teleports (18 GB vs 4 GB) -- size the limit to available memory and evict undriven decoded copies #636