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

Lithus commented

2026-09-28 10:15:54 +00:00

Environment

Slipstream Beta 0.12.0.26 (64bit) (SSE4_2)
Release Notes

You are at 64.8, 135.1, 14.2 in The Mares Nest located at simhost-08d9755af793773b6.agni
SLURL: http://maps.secondlife.com/secondlife/The%20Mares%20Nest/65/135/14
(global coordinates 257,345.0, 281,991.0, 14.2)
Second Life RC Magnum 2026-09-22.35767837201
Release Notes

CPU: AMD Ryzen 7 5800X 8-Core Processor (3800.04 MHz)
Memory: 32694 MB
Concurrency: 16
OS Version: Microsoft Windows 11 64-bit (Build 26200.9457)
Graphics Card Vendor: NVIDIA
Graphics Card: NVIDIA GeForce RTX 3070 Ti

Windows Graphics Driver Version: 32.0.16.1074
OpenGL Version: Vulkan 1.4.341

Window size: 2560x1334
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 256m
Bandwidth: 10000kbit/s
LOD factor: 4
Render quality: 6
Texture memory: 8017MB
Disk cache: Max size 5734.4 MB (33.4% used)

RestrainedLove API: RLV v3.4.3 / RLVa v2.5.0.26
libcurl Version: libcurl/7.54.1 OpenSSL/1.1.1w zlib/1.3.1.zlib-ng nghttp2/1.66.0
J2C Decoder Version: OpenJPEG Runtime: 2.4.0
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.24.3 / OpenAL Community / OpenAL Soft: OpenAL Soft
Dullahan: 1.23.0.202509121212
CEF: 140.1.13+g5eb3258+chromium-140.0.7339.41
Chromium: 140.0.7339.41
LibVLC Version: 3.0.21
Voice Server Version: Secondlife WebRTC Gateway

Compiler Version: Clang 22.1.6
Packets Lost: 27/433,577 (0.0%)
September 28 2026 03:11:08

Description

Changing graphic settings doesn't affect the quality, nor does hopping to another. Then back to the sim.
Texture Refresh also doesn't seem to work at all.
Never seems to be on your own avatar or the world, only others.

Reproduction steps

Sometimes happens to others when hopping sims. But more reliably happens when someone joins the sim you're in.

### Environment Slipstream Beta 0.12.0.26 (64bit) (SSE4_2) Release Notes You are at 64.8, 135.1, 14.2 in The Mares Nest located at simhost-08d9755af793773b6.agni SLURL: http://maps.secondlife.com/secondlife/The%20Mares%20Nest/65/135/14 (global coordinates 257,345.0, 281,991.0, 14.2) Second Life RC Magnum 2026-09-22.35767837201 Release Notes CPU: AMD Ryzen 7 5800X 8-Core Processor (3800.04 MHz) Memory: 32694 MB Concurrency: 16 OS Version: Microsoft Windows 11 64-bit (Build 26200.9457) Graphics Card Vendor: NVIDIA Graphics Card: NVIDIA GeForce RTX 3070 Ti Windows Graphics Driver Version: 32.0.16.1074 OpenGL Version: Vulkan 1.4.341 Window size: 2560x1334 Font Size Adjustment: 96pt UI Scaling: 1 Draw distance: 256m Bandwidth: 10000kbit/s LOD factor: 4 Render quality: 6 Texture memory: 8017MB Disk cache: Max size 5734.4 MB (33.4% used) RestrainedLove API: RLV v3.4.3 / RLVa v2.5.0.26 libcurl Version: libcurl/7.54.1 OpenSSL/1.1.1w zlib/1.3.1.zlib-ng nghttp2/1.66.0 J2C Decoder Version: OpenJPEG Runtime: 2.4.0 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.24.3 / OpenAL Community / OpenAL Soft: OpenAL Soft Dullahan: 1.23.0.202509121212 CEF: 140.1.13+g5eb3258+chromium-140.0.7339.41 Chromium: 140.0.7339.41 LibVLC Version: 3.0.21 Voice Server Version: Secondlife WebRTC Gateway Compiler Version: Clang 22.1.6 Packets Lost: 27/433,577 (0.0%) September 28 2026 03:11:08 ### Description Changing graphic settings doesn't affect the quality, nor does hopping to another. Then back to the sim. Texture Refresh also doesn't seem to work at all. Never seems to be on your own avatar or the world, only others. ### Reproduction steps Sometimes happens to others when hopping sims. But more reliably happens when someone joins the sim you're in.

Lithus added the

bug

label

2026-09-28 10:15:54 +00:00

Durpy337 commented

2026-09-28 18:27:55 +00:00

Encountering the same issue with world textures, nothing loads fully unless your camera position is close to texture on geometry. Left the application running overnight only to finally keep the textures loaded, though new avatars remain to have low res texture resolution.

sky_line commented

2026-09-29 03:29:09 +00:00

Owner

Still getting reports of slow or no avatar mesh/texture loading in the current release (v0.12.0-beta.3), so this isn't fixed yet. Needs another pass: collect a Slipstream.log from an affected user (with the avatar's name / time of the stall), and check the texture fetch/decode queue, bindless residency for avatar textures (BOOST_AVATAR demand), and whether rigged meshes waiting on skin info / LOD ever retry.

Still getting reports of slow or no avatar mesh/texture loading in the current release (**v0.12.0-beta.3**), so this isn't fixed yet. Needs another pass: collect a Slipstream.log from an affected user (with the avatar's name / time of the stall), and check the texture fetch/decode queue, bindless residency for avatar textures (BOOST_AVATAR demand), and whether rigged meshes waiting on skin info / LOD ever retry.

sky_line commented

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

Owner

New report: a user with 16 GB of system RAM has a lot of trouble getting avatars to load.

Likely mechanisms

1. LL's low-memory texture throttle (most likely). LLViewerTexture::updateClass / isSystemMemoryLow(): when free system RAM drops under RenderMinFreeMainMemoryThreshold (512 MB), sDesiredDiscardBias is slammed up and then keeps ramping while memory stays low.

Textures get forced to coarser discard levels, i.e. "super low res / never sharpen".
Off-screen textures are emergency-purged, logged as Low system memory detected, emergency downrezzing off screen textures.
Object loading is throttled too (llvocache.cpp: SceneLoadLowMemoryBound once the bias passes 2).

We measured a busy two-sim view at 28.3 GB RSS, 16.7 GB of it CPU texture copies (#159). A 16 GB machine would sit permanently in this state.

2. Failed Vulkan allocations are silent. VkDeviceContext::softFail skips OUT_OF_HOST/DEVICE_MEMORY allocations, so the upload / buffer just doesn't happen (missing textures or meshes). It reports at most once a minute and only to stderr, so it never reaches Slipstream.log on Windows. Host-visible staging is the likeliest to fail on a 16 GB system.

To do

Get the user's Slipstream.log. Search for Low system memory detected to confirm (1).
Route softFail (and RT's allocation-failure paths) to LL_WARNS, plus a counter in the VKMem line.
Log discard bias + free system memory in the periodic VKMem / SECTIONS line, so low-memory throttling is visible in any report.
Fix the root: #159 (drop CPU texture copies after upload), #160 (staging size).

New report: a user with **16 GB of system RAM** has a lot of trouble getting avatars to load. ## Likely mechanisms **1. LL's low-memory texture throttle (most likely).** `LLViewerTexture::updateClass` / `isSystemMemoryLow()`: when free system RAM drops under `RenderMinFreeMainMemoryThreshold` (512 MB), `sDesiredDiscardBias` is slammed up and then **keeps ramping** while memory stays low. - Textures get forced to coarser discard levels, i.e. "super low res / never sharpen". - Off-screen textures are emergency-purged, logged as `Low system memory detected, emergency downrezzing off screen textures`. - Object loading is throttled too (`llvocache.cpp`: `SceneLoadLowMemoryBound` once the bias passes 2). We measured a busy two-sim view at **28.3 GB RSS**, 16.7 GB of it CPU texture copies (#159). A 16 GB machine would sit permanently in this state. **2. Failed Vulkan allocations are silent.** `VkDeviceContext::softFail` skips OUT_OF_HOST/DEVICE_MEMORY allocations, so the upload / buffer just doesn't happen (missing textures or meshes). It reports at most once a minute and **only to stderr**, so it never reaches Slipstream.log on Windows. Host-visible staging is the likeliest to fail on a 16 GB system. ## To do - [ ] Get the user's Slipstream.log. Search for `Low system memory detected` to confirm (1). - [ ] Route `softFail` (and RT's allocation-failure paths) to `LL_WARNS`, plus a counter in the VKMem line. - [ ] Log discard bias + free system memory in the periodic VKMem / SECTIONS line, so low-memory throttling is visible in any report. - [ ] Fix the root: #159 (drop CPU texture copies after upload), #160 (staging size).

sky_line referenced this issue

2026-09-29 06:00:00 +00:00

VRAM: ray tracing must fit a VRAM-scaled budget, below textures (8 GB cards starve) #164

sky_line commented

2026-09-29 06:00:00 +00:00

Owner

Diagnosed from the 16 GB user's log (RX 7600, 8 GB): VRAM starvation, not RAM. No Vulkan allocation failures (the "OUT_OF_" hits were network packet_out_of_order), and the low-system-memory throttle fired once.

Final VKMem line:

heap0(dev) 5487/6484MB | tex 367MB 11366 imgs [residency budget 3891MB bias 7 ... floor 10560 pending up 9931]
staging 1925 as 1910 (15937 blas) rt-aux 1080 | geom vbo 422 ibo 157 wgt 113 skin 283 tables 393

RT (AS 1,910 incl. rigged 912 MB, aux 1,080) + staging (1,925) take ~5 GB of the card.
Texture residency is squeezed to 367 MB at mip bias 7: 10,560 of 11,366 images at the floor, 9,931 upgrades pending forever. That's the "avatars don't load / super low res".
Earlier the bias thrashes 0<->1<->2<->3 every few seconds (pressure -> drop -> re-upload -> pressure).

They were on beta.4: per-face rigged BLAS (fixed since by per-avatar groups, 800be372e2, about half the rigged BLAS memory) and full-size mirrored staging (reduced by b1d58c199b, peak-retention still open in #160).

Workaround for the user: Projector Shadows -> Shadow maps (or off) and RenderVKRayTracing 0, then restart. That frees ~3 GB.

Fixes: #164 (RT memory budget covering all RT, scaled to VRAM, textures first), #160 (staging), #161 (RT aux), and bias hysteresis (in #164).

**Diagnosed from the 16 GB user's log (RX 7600, 8 GB): VRAM starvation, not RAM.** No Vulkan allocation failures (the "OUT_OF_" hits were network `packet_out_of_order`), and the low-system-memory throttle fired once. Final VKMem line: ``` heap0(dev) 5487/6484MB | tex 367MB 11366 imgs [residency budget 3891MB bias 7 ... floor 10560 pending up 9931] staging 1925 as 1910 (15937 blas) rt-aux 1080 | geom vbo 422 ibo 157 wgt 113 skin 283 tables 393 ``` - RT (AS 1,910 incl. **rigged 912 MB**, aux 1,080) + staging (1,925) take ~5 GB of the card. - Texture residency is squeezed to **367 MB at mip bias 7**: 10,560 of 11,366 images at the floor, 9,931 upgrades pending forever. That's the "avatars don't load / super low res". - Earlier the bias **thrashes** 0<->1<->2<->3 every few seconds (pressure -> drop -> re-upload -> pressure). They were on beta.4: per-face rigged BLAS (fixed since by per-avatar groups, `800be372e2`, about half the rigged BLAS memory) and full-size mirrored staging (reduced by `b1d58c199b`, peak-retention still open in #160). Workaround for the user: Projector Shadows -> Shadow maps (or off) and `RenderVKRayTracing` 0, then restart. That frees ~3 GB. Fixes: #164 (RT memory budget covering all RT, scaled to VRAM, textures first), #160 (staging), #161 (RT aux), and bias hysteresis (in #164).

sky_line referenced this issue from a commit

2026-09-29 06:08:23 +00:00

RT: release all BLAS / TLAS / RT buffers after 15 s without a consumer

sky_line referenced this issue from a commit

2026-09-29 06:38:47 +00:00

VRAM: one scaled RT budget that yields before textures; bias hysteresis

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

2026-09-29 18:19:26 +00:00

VK diag: RenderVKDumpAvatar -- ingest dump of every attachment an avatar wears

sky_line referenced this issue from a commit

2026-09-29 21:23:18 +00:00

VK diag: avatar/selection dump lists each PBR map's texture streaming state

sky_line commented

2026-09-30 00:03:34 +00:00

Owner

Likely root cause found and fixed in 1063b62646 (pushed): the Vulkan cull sized textures on OTHER people's rigged meshes and worn attachments from their instance bounds, but those instances' model_matrix is not a world pose (skin palette / joint-local), so the demand landed near the region origin and asked for the 64 px floor. RenderVKDumpAvatar on an affected avatar showed its PBR maps at 64x64 of 1024x1024 with want=4, vsize=4096, nothing fetching. Demand now comes from the wearer's real distance and size.

Confirmed in-world on one avatar that was consistently low-res. Leaving open until testers confirm on the next release -- if it persists for anyone, a RenderVKDumpAvatar log of the affected avatar is the thing to capture.

Likely root cause found and fixed in 1063b62646 (pushed): the Vulkan cull sized textures on OTHER people's rigged meshes and worn attachments from their instance bounds, but those instances' model_matrix is not a world pose (skin palette / joint-local), so the demand landed near the region origin and asked for the 64 px floor. RenderVKDumpAvatar on an affected avatar showed its PBR maps at 64x64 of 1024x1024 with want=4, vsize=4096, nothing fetching. Demand now comes from the wearer's real distance and size. Confirmed in-world on one avatar that was consistently low-res. **Leaving open until testers confirm on the next release** -- if it persists for anyone, a RenderVKDumpAvatar log of the affected avatar is the thing to capture.

sky_line referenced this issue from a commit

2026-09-30 00:03:34 +00:00

VK texture demand for rigged meshes / worn attachments from the wearer

sky_line referenced this issue

2026-09-30 01:14:28 +00:00

PBR + BOM: other avatars show the IMG_USE_BAKED_* placeholder text instead of their bake #192

sky_line commented

2026-09-30 01:14:33 +00:00

Owner

Follow-up found once textures sharpened: PBR faces on BOM bodies show the IMG_USE_BAKED_* placeholder text (the VK PBR path doesn't substitute the bake) -- tracked in #192.

sky_line referenced this issue from a commit

2026-09-30 03:17:15 +00:00

VK avatar dump: streaming state for legacy (Blinn-Phong) textures too

sky_line referenced this issue from a commit

2026-09-30 04:48:02 +00:00

VK: rigged meshes with fewer than 4 joints are valid (invisible avatar body)

sky_line commented

2026-10-05 01:25:52 +00:00

Owner

Closing this as we believe it's fixed in the current version, 1.0.0 Beta 8 (https://slipstreamviewer.org/download). Please test on Beta 8, and if the problem is still there, re-open this ticket (or reply here) with what you see. A Slipstream.log from the session helps a lot. Thanks for the report!

Closing this as we believe it's fixed in the current version, **1.0.0 Beta 8** (https://slipstreamviewer.org/download). Please test on Beta 8, and if the problem is still there, re-open this ticket (or reply here) with what you see. A Slipstream.log from the session helps a lot. Thanks for the report!

sky_line closed this issue

2026-10-05 01:25:52 +00:00

Rows
Columns

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

Environment

Description

Reproduction steps

Likely mechanisms

To do