Dan Linden I've been mostly using the mac lately, but i will do some testing with 26.3 on the pc, with different cache sizes (prioritising the default value of 6gb) ), see if this issue is still a real issue today. I tend to use low cache values due to the fact that i don't have that much free space. Also i am using a fast ssd.

as a side note: not directly related, but still a bit related, i still use the pc mostly for testing sometimes, and also made some test with the previous 26.3 beta that included the work of geenz on the texture streaming. I found the approach interesting, even so, sadly it wasn't tuned correctly (truth is there was quite many parameters to take into account) resulting to over agressive texture discarding (you reverted those changed for now). With some tweaking i managed to make textures not looking so blurry, but it wasn't ideal. The amount of textures in some places is so enormous that i understand the challenge this is to make this work smoothly on a less than 16gb gpu (6 or 8gb).

anyways, i will be doing some test on the PC with the nvidia gpu and complete this post as soon as i can.

Dan Linden I tested in different places, and the situation is better than it was when first posted this in 2025. The main difference being: The texture streaming is stabilizing after a moment, if i don't move, while, back then it was in a loop.

I found the exact place i was testing it also: https://maps.secondlife.com/secondlife/Itame/52/47/83

This place is interesting because the volume of texture + vertices is about 8gb with my settings. So the nvidia gpu is at its limit, resulting to some fetching when looking around. I compared with the integrated gpu (amd), with same settings. The igpu is less powerful of course, but it can use up to 16gb of ram as "vram", so it's just smoother than the nvidia when looking around (much less fetching, despite texture + vertices being less than 8gb, but it has this little headroom the nvidia gpu doesn't have).

so overall, it's better than it was on the nvidia gpu, in this place and others. It's just not "super smooth" due to the fact 8gb of vram is now barely sufficient.

also limiting the max texture resolution to 512x512 instead of 1024 results to the free estimated memory raising to about 3300mb, while it's around 0 with 1024 x 1024. That's why i think 512 x 512 should be recommended for gpu with less vram, under memory pressure at least.

AlettaMondragon Resident It seems to happen with objects textures, not avatar textures. It seems avatar textures are managed differently?

As if i go to a crowdy place, the estimated remaining vram goes way down in the negative, and doesn't cause this cycle of "cleaning and refilling". While if i go to a sim with no or few people, but with loads of textures, the estimated available cram will be limited to positive value, and that's when the cycle begins.

As a side note, crowdy place also immensely raise the memory needed for vertices, up to a point it sometimes equals the textures memory (4 or 5 gb of estimated vertices memory). But it doesn't cause the same issue.

Reaching low estimated available textures vram, the viewer does an emergency cleaning, so the vram goes up for a few seconds, then, as it has more estimated available vram, it will start loading textures again until reaching that low value.

I've seen it happenning on a 6gb and a 8gb vram gpus. A friend had this on a 12gb vram gpu (rtx 4070).

In this case the only solution is to lower the maximum texture resolution setting to 512.

(I haven't tried driving because i don't have a car and the rights where sims traversal is possible)

Since the stutter is certainly caused by images decoding, it's possible that it's not as much perceptible on super high end CPUs.

Also maybe by using a large disk cache, it helps? but i'm not sure if images stored in cache are actually decoded or stored as the native jpeg2 downloaded files. I'm usually using a rather small cache.

I also don't have this issue on the Macbook Pro, because it has enormous amount of ram/vram.

On the AMD igpu, the issue isn't occurring, at least in the same scene, certainly because it can allocate up to 16gb of ram as vram.

(On Linux, using a viewer that is heavily based on LL code, megapahit, the problem didn't occur last time i checked, or not in the same scene. I might do some more tests to see what happens on Linux as for what available vram is reported here. EDIT -> It does happen on Linux too, it's just that i had the max texture lod set to 512. as soon as i switch to 1024 or 2048, that's where it happens).

observeur Resident This seems really similar to the problems that were fixed (somewhat, at least) in Firestorm. Maybe the fix didn't make it to the SLV.

AlettaMondragon Resident I'm doing some more testing.

So i made some more testing. It seems that in Firestorm, according to the textures console, instead of entering this periodic cycle, it doesn't cleanup textures so aggressively, but instead keeps loading and reloading a smaller number of textures, resulting to overall lower performance BUT better consistency.

I also tested in SLv 7.2.2.17774206511 and .. this version seems to behave a bit like Firestorm in that regard. (it also has slightly better performance than Firestorm).

observeur Resident So by slightly better performance and better consistency (with SLV 7.2.2 and FS 7.1.13 respectively) you mean the stutters are still happening, just not as often, not as severely?

Dan Linden Hello Dan. I will try this in a lil moment :) (i was using the shared environment)

Dan Linden I tested with changing the environment .. midday legacy, midday, midnight sunrise .. this doesn't affects the issue. However if i open the textures console, i see a periodic

cycle where the textures are loading up, until the estimated free vram goes in the negative, then it must be cleaning up .. so the estimated vram is going up, and then refilling .. and that where the stutter occurs.

The previous tests were made with texture lod set to 1024x1024 pixels, here i set it to 512x512 and the vram isn't saturated. The periodic stutter doesn't occur. Now i am not sure if there is a mechanism in the viewer that would actually limit textures resolution the same way the textures lod settings does, instead of .. whatever it does now, in the case of vram saturation? At least to keep the viewer smooth. I'm also wondering how vram usage is managed in Linux vs Windows, because i didn't have the stutter in Linux (using megapahit in that case). (but the estimated free vram was deep in the negatives .. so probably using ram in this case?)

KDU vs OpenJpeg seems to help .. IF the there aren't too many textures reloading in this "cycle".