Stutters on Windows / NVidia
observeur Resident
(this might be a refresh of https://feedback.secondlife.com/bug-reports/p/202503-viewer-intense-stutter-on-a-nvidia-windows-laptop)
in certain places like this :
The viewer can show important stutter on Windows and NVidia gpus, specially after spinning around.
The issue doesn't seem to occur on the integrated AMD graphics.
I also have the issue in megapahit, which i could try on Linux, and on Linux it's perfectly smooth. So it seems to be specific NVidia + Windows.
The issue happens in my both PC laptops (gtx 1660ti / rtx 3080m both with an AMD cpu).
(in my setting i have reflection coverage to manual only, hdr & emissive on, only show friends to avoid avatars interferences).
Also the issue doesn't seem to be related to avatars, because i tested crowded sims and it wasn't too bad.
Log In
AlettaMondragon Resident
observeur Resident Does this also happen to you if you go to a busy club for example, with a lot of people moving around, dancing, etc? Or if you drive through many regions that have a lot of objects around in direct view?
observeur Resident
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).
Dan Linden
open
Dan Linden
needs info
Dan Linden
Hi observeur.
I was not yet able to reproduce the issue at that location but it reminds me of a stutter I saw,
When you see the stutter, can you try seeing if different Environments (Sunrise, Midday, etc.) affect it? If it's affected by Environments, which is the worst?
observeur Resident
Dan Linden Hello Dan. I will try this in a lil moment :) (i was using the shared environment)
observeur Resident
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".