Firestorm is one hell of a memory hog

[Profaitchikenz Haiku]

2 hours ago, NiranV Dean said:

Btw, i disabled full res textures

Now you'd probably be best placed to answer this question: if you clamp textures to 512Mb (as Firestorm and presumably your viewer allow), does the texture download still grab the full-sized texture from the web and then store it in cache as such, and merely present a 512 max to the screen? My tests doing this showed no change in cache texture folder size after visiting three standard places I use.

It would be ever so smart a trick to reduce the cached texture stored size appropriately, if it's possible to do this to Jpeg2000 on the fly.

Edited December 16, 2019 by Profaitchikenz Haiku

[NiranV Dean]

6 hours ago, Profaitchikenz Haiku said:

Now you'd probably be best placed to answer this question: if you clamp textures to 512Mb (as Firestorm and presumably your viewer allow), does the texture download still grab the full-sized texture from the web and then store it in cache as such, and merely present a 512 max to the screen? My tests doing this showed no change in cache texture folder size after visiting three standard places I use.

It would be ever so smart a trick to reduce the cached texture stored size appropriately, if it's possible to do this to Jpeg2000 on the fly.

My Viewer does not have an option to cap the max texture size, but this is an interesting question nonetheless. I'd guess that if you limit the texture size you'll end up saving the max resolution one into cache regardless but it depends on where exactly said limitation is applied, is it applied pre or post determining texture size and downloading it and then it would also depend on how well the entire caching and interest list thing works and whether it keeps them around or simply drops them the moment you revert to a lower resolution (i'd guess not).

Also, with "Full Res Textures" i meant a debug setting that forces the Viewer to load all textures on their maximum available resolution regardless of settings and memory limits, this will quickly fill up your entire VRAM and slow the Viewer down to a crawl because your GPU will be more busy with swapping textures than doing anything useful. I highly recommend you NEVER touch this option EVER unless you want to see the Viewer burn, or test how well all the Viewer internal systems work and how much they save in comparison to how it would be if they wouldn't work at all. That's exactly what i did here, i wanted to see the Viewer crash and burn (spoiler, it didn't) to show you that a bit more memory usage is absolutely laughable compared to what is actually lurking in SL's content.

Edited December 16, 2019 by NiranV Dean

[Ardy Lay]

The debug setting NiranV Dean used disables "discard bias".  Discard bias is an attempt to reduce texture resolution on screen to suit the apparent size of the face it occupies on screen.  It also gets another push downward when textures being applied to faces are taking up more than a soft limit derived from a viewer setting that gets a lot of discussion time in the forums when people are talking about things getting blurry and texture "churn".  I would like for somebody to fix the texture console display NiranV Dean told us overflowed.  It's kinda comical when that happens as it goes up, snaps to a large negative value, goes down then back up again and snaps large negative again.  In some places it does indeed keep doing this, losing significant bits in the display, until the GPU's direct access memory is filled and software starts using shared CPU memory for the rendering buffers.  Yes in deed this does slow things down to "Oh damn.  She's gonna implode now!" frame rates but usually what happens if I let it keep plugging along is the agent connection to the simulator times out!  Still, knowing what the perils are, I use this debug setting a lot, to combat the texture churn, because my frame rate doesn't really drop until Windows Task Manager indicates 7GB of GPU memory is in use.

And, of course, your "mileage" may vary.  Unfortunately not everyone can justify the cost of the hardware I am using.

[NiranV Dean]

18 hours ago, Ardy Lay said:

The debug setting NiranV Dean used disables "discard bias".  Discard bias is an attempt to reduce texture resolution on screen to suit the apparent size of the face it occupies on screen.  It also gets another push downward when textures being applied to faces are taking up more than a soft limit derived from a viewer setting that gets a lot of discussion time in the forums when people are talking about things getting blurry and texture "churn".  I would like for somebody to fix the texture console display NiranV Dean told us overflowed.  It's kinda comical when that happens as it goes up, snaps to a large negative value, goes down then back up again and snaps large negative again.  In some places it does indeed keep doing this, losing significant bits in the display, until the GPU's direct access memory is filled and software starts using shared CPU memory for the rendering buffers.  Yes in deed this does slow things down to "Oh damn.  She's gonna implode now!" frame rates but usually what happens if I let it keep plugging along is the agent connection to the simulator times out!  Still, knowing what the perils are, I use this debug setting a lot, to combat the texture churn, because my frame rate doesn't really drop until Windows Task Manager indicates 7GB of GPU memory is in use.

And, of course, your "mileage" may vary.  Unfortunately not everyone can justify the cost of the hardware I am using.

When i was talking about overflowing my texture console i was talking about my own version of it, it goes up to 4096 before it snaps back to 0 (but internally continues counting properly, it will go back to 4096 if it goes below 0 again), the reason it overflows like that is because its capped at 4096 because you can only set 4096 for scene and texture memory each (totalling at 8gb), the texture console was never designed to be "blown" up the way i did but i'd like to fix it regardless, along with the memory bars going invisible at around 4gb for some mysterious reason.

Edited December 18, 2019 by NiranV Dean