Firestorm's Dynamic Texture memory settings

[Jackson Redstar]

I am a bit confused their description for this for me at least, is jibberish at best. Anybody know how this feature actually is supposed to work?

I have 8 gigs VRAM memory and 32 gig RAM memory. All my drives in my system are SSD, BTW

[Solar Legion]

Eight gigs of VRAM? You should be good to set the main slider at the maximum with the other two set similarly to how I have mine: No more than a ten.

The description/tooltips aren't gibberish whatsoever either. Top slider is texture buffer allocation (same as the original function above it), middle slider is additional cache for textures not presently being displayed (so they load in faster when they are finally displayed) while the bottom slider is a percentage of your VRAM reserved for all other functions.

[arabellajones]

I'd class the pop-ups as a reminder for people who already know. They have the same weakness of assumed knowledge as the setting for "Bandwidth", which only applies to the UDP traffic, now mostly used for command and control signals, and has nothing to do with textures.

I've been worrying about it, the descriptions (there are at least two in the Firestorm Wiki) are a bit vague about just what the sliders do, and it all comes across as a bit of automatic magic. It also needs vendor-specific graphics cards extensions in OpenGL before you even see the controls.

Anyway, here's a link. Good luck, guys, I think you'll need it.

Firestorm graphics preferences: hardware settings.

[Jackson Redstar]

ok thanks i think that helps....  wasnt sure if this was stuck in the dark ages like bandwidth - most of use now in the hundreds of mbps download speeds and the recommended is seemly when we were still using max of 5mbps download speeds circa 2005 lol. still don't know why that hasn't been ditched already and just use what we got

Edited August 11, 2021 by Jackson Redstar

[NiranV Dean]

Let me translate this for you.

Your Graphics Card has a certain amount of memory (VRAM), this memory is used to store data (textures for all kinds of stuff but mainly for the things to render but also textures that contain information, such as shadow position, lighting information etc). SL just like any other application needs it to store its textures in order to render them. You get two "ways" to configure this, either the manual way (which is what we were used to for the longest part) with a single texture memory slider which internally controls two values that determine how much of that precious VRAM the Viewer is allowed to use for what kind of texture (see below) and the automatic way which can be enabled with "Enable Dynamic Texture Memory" which essentially aims to take away the fiddling while aiming to leave you in control how much memory the Viewer is allowed to use. With Dynamic Texture Memory you get two options, one which allows you to set the bare minimum the Viewer should always get and another one that allows you to set a "reserve" which acts as a no-go amount for the Viewer which is left free for other applications. The maximum amount of VRAM the Viewer will use with Dynamic Texture Memory enabled will be whatever your Graphics Card physically has minus what you've set as "reserve", the minimum is directly set, so the actual usage will vary in-between those two. Dynamic Texture Memory also allows the Viewer to use more than 2GB VRAM (unlike the manual mode, which is not true btw, again see below below).

The Viewer actually has two memory pools, one being the overall memory pool which is supposedly used for long-term storage, currently used, semi permanent and permanent textures such as UI textures go in here, this is the larger of the two pools as it always contains the other in addition to everything currently not used but still loaded. The other pool (i call it the scene pool) is used for the very image you are currently seeing and only contains whatever is needed to produce this very frame you are currently viewing, this pool as mentioned before is also included in the other pool, effectively using double the amount of texture memory for all currently on-screen textures.

The above means that the "Texture Memory" slider effectively controlled two things, both pools and neither of them accurately. 512MB Texture Memory is actually 1GB (~700MB main and 300MB scene pool), setting this to 1GB effectively made the Viewer use up to 2GB and setting it to 2GB effectively up to 4GB, which is PROBABLY why the setting only allows you to go up to 2048MB even if you have 4GB. 

Note that Dynamic Texture Memory only works on Graphics Cards (and their drivers) that properly report their memory (AMD really doesn't for the most part, which is an issue i've been fighting for a long time).

If anything i think manual texture memory should go away once and for all, have the Viewer use whatever is available and if anything add a configurable reserve. I've done it, every *****ing app and game in existence does it, SL should do it too, there is no point in having a setting that confuses people and leads to texture trashing.

[Beq Janus]

41 minutes ago, NiranV Dean said:

If anything i think manual texture memory should go away once and for all, have the Viewer use whatever is available and if anything add a configurable reserve. I've done it, every *****ing app and game in existence does it, SL should do it too, there is no point in having a setting that confuses people and leads to texture trashing.

I kinda agree, except that any time we do that we have 50% of people telling us we're wrong anyway. 

[NiranV Dean]

8 hours ago, Beq Janus said:

I kinda agree, except that any time we do that we have 50% of people telling us we're wrong anyway. 

I've had memory management automated for ... idk 2 years? or so if not longer and i have practically reduced any reports of texture trashing to zero.

[Chic Aeon]

I am not going to "quote" this as each time I quote my message gets blocked (no clue but new -- a bot?).

SO 

• If anything i think manual texture memory should go away once and for all, have the Viewer use whatever is available and if anything add a configurable reserve.

 

 

Just wanted to note that this is how things worked in Sansar. The viewer took whatever was available LOL.  I never had any issue and didn't really hear of other folks having issues. Of course most of the crew were on pretty hefty machines.  Sorry I can't get rid of the CSS  in this comment. 

 

But it MAY actually post. 

[UnknownPedestrian]

On 8/11/2021 at 9:47 AM, NiranV Dean said:

Let me translate this for you.

Your Graphics Card has a certain amount of memory (VRAM), this memory is used to store data (textures for all kinds of stuff but mainly for the things to render but also textures that contain information, such as shadow position, lighting information etc). SL just like any other application needs it to store its textures in order to render them. You get two "ways" to configure this, either the manual way (which is what we were used to for the longest part) with a single texture memory slider which internally controls two values that determine how much of that precious VRAM the Viewer is allowed to use for what kind of texture (see below) and the automatic way which can be enabled with "Enable Dynamic Texture Memory" which essentially aims to take away the fiddling while aiming to leave you in control how much memory the Viewer is allowed to use. With Dynamic Texture Memory you get two options, one which allows you to set the bare minimum the Viewer should always get and another one that allows you to set a "reserve" which acts as a no-go amount for the Viewer which is left free for other applications. The maximum amount of VRAM the Viewer will use with Dynamic Texture Memory enabled will be whatever your Graphics Card physically has minus what you've set as "reserve", the minimum is directly set, so the actual usage will vary in-between those two. Dynamic Texture Memory also allows the Viewer to use more than 2GB VRAM (unlike the manual mode, which is not true btw, again see below below).

The Viewer actually has two memory pools, one being the overall memory pool which is supposedly used for long-term storage, currently used, semi permanent and permanent textures such as UI textures go in here, this is the larger of the two pools as it always contains the other in addition to everything currently not used but still loaded. The other pool (i call it the scene pool) is used for the very image you are currently seeing and only contains whatever is needed to produce this very frame you are currently viewing, this pool as mentioned before is also included in the other pool, effectively using double the amount of texture memory for all currently on-screen textures.

The above means that the "Texture Memory" slider effectively controlled two things, both pools and neither of them accurately. 512MB Texture Memory is actually 1GB (~700MB main and 300MB scene pool), setting this to 1GB effectively made the Viewer use up to 2GB and setting it to 2GB effectively up to 4GB, which is PROBABLY why the setting only allows you to go up to 2048MB even if you have 4GB. 

Note that Dynamic Texture Memory only works on Graphics Cards (and their drivers) that properly report their memory (AMD really doesn't for the most part, which is an issue i've been fighting for a long time).

good news, the fight stops now! update your chipset driver and graphics driver from AMD and Be happy that they finally patched GL_ATI_meminfo back into the drivers! yay compatibility!

[Kathrine Jansma]

On 1/15/2023 at 3:33 PM, UnknownPedestrian said:

Update your chipset driver and graphics driver from AMD and Be happy that they finally patched GL_ATI_meminfo back into the drivers! yay compatibility!

At least AMD Driver 22.11.2 fails to report proper memory on Windows if both a 5700G APU & Vega 56 card are in the system. I get stuff like 22 GB of VRAM reported in that combination.

 

[Modulated]

53 minutes ago, Kathrine Jansma said:

At least AMD Driver 22.11.2 fails to report proper memory on Windows if both a 5700G APU & Vega 56 card are in the system. I get stuff like 22 GB of VRAM reported in that combination.

 

I have seen those vega cards for very good prices on ebay lately, how well does it run SL for you?

[Kathrine Jansma]

A mid range NVIDA card would have been a better choice for SL. The Vega burns quite some energy, if you run it on Linux it is halfway decent, on Windows it gets better with the newer drivers. 

The performance is kind of acceptable, but NVIDIA cards usually blow it out of the water for OpenGL like SL. For example, when visiting some club with 20+ AVs around my FPS tend to drop to 15-25 or so (with AMDs older drivers it was like 5-12 fps), while Henri reported 70fps with his older 1070 card and same graphics settings (but a little faster CPU) when we looked at some issue a few months back.

I would probably get an NVIDIA card instead if it is specifically for SL. 

[NiranV Dean]

On 1/15/2023 at 3:33 PM, UnknownPedestrian said:

good news, the fight stops now! update your chipset driver and graphics driver from AMD and Be happy that they finally patched GL_ATI_meminfo back into the drivers! yay compatibility!

That's amazing news, now lets just get everyone on AMD to update their GPU drivers and hope they didn't introduce a million new issues (again again again again again again)