Jump to content

Firestorm's Dynamic Texture memory settings


You are about to reply to a thread that has been inactive for 75 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Posted (edited)

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 by Jackson Redstar
Link to comment
Share on other sites

image.thumb.png.99c4963db962f252cf1f32957f1a75fa.png

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 75 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...