Firestorm viewer - Dynamic Memory settings

[Jackson Redstar]

Can a FS viewer guru explain this? I really dont know what the 'best' settings are for my system (or for that matter even with their explanation what it really means)

RTX 3070 with 8g of VRAM

32gig RAM

Intel i7

Samsung 1T SSD main drive

What I notice if I am in a really busy sim with lots of people and 'everything on' often my VRAM usage push right at the full 8 gigs sometimes a little more. Which may or may not be a big deal, I dont know. Right now my Dynamic memory is at its default state - Min memory buffer 2048 and the other 2 percentages set at 15%

Im just trying to make sure my memory settings are running at optimum efficiency 

[Rachel1206]

I max Enable Dynamic Texture Memory to 4032 MB with my RTX 3080 8 GB VRAM, never encountered any problems. Even with Chrome browser, video creation software running, no problems.

Additional Texture Memory Cache Reserve: 10%
Physical Video Memory Reserve: 10%

Assuming you do run any other VRAM heavy software at the same time as your viewer, you should not get any problems.

Now I noticed you have Fog Distance Ratio enabled. Enable Atmospheric shaders instead, your RTX GPU and the GeForce drivers handles this much more efficient, faster  and in high quality. You find Atmospheric shaders in Graphics->General

Enabling Atmospheric shaders will disable Fog Distance Ratio.

Edited April 26, 2022 by Rachel1206
Clarification

[Beq Janus]

There's not really a general "optimum setting".  It depends a lot on what else you have running on the machine and so forth.

What we're basically allowing you to do here is provide strong hints to openGL about how much VRAM you can use. Due to the way OpenGL works actual VRAM usage is governed by the driver so the viewer has only indirect influence. 

What you probably want to consider is how much VRAM other programs need as well and make sure they have enough, if you over allocate you'll just end up with the drivers discarding stuff anyway. But OpenGL does take most of the control so in the end you are somewhat constrained and if a busy sceen is really pushing you to max that is sadly how it is and you have to let the opengl driver do its job.

You might find the help text (click on the ? at the top of the floater) useful, though it isn't worded very clearly. (suggested edits most welcome)

Quote

Enable Dynamic Texture Memory: Allows the viewer to use more than 2GB of texture memory. Dynamic Texture Memory only works on 64-bit viewers with at least 512MB VRAM and GPUs supporting and reporting either GL_ATI_meminfo (AMD) or GL_NVX_gpu_memory_info (NVIDIA) vendor-specific OpenGL extensions. It will allow using all currently available VRAM, or at least the value specified in minimum viewer texture memory capped at physical VRAM, minus VRAM reserve for allocating textures. That value minus cache reserve is the texture memory available for textures actually

Here is a very explicit explanation of what those numbers get used for (I realise that this may not be helpful to you but it hopefully builds on the help text a little)

What we want to do is get a number that represents the maximum VRAM  ask, based upon the user settings.

Minimum Viewer Texture Buffer is used as our "minimum ask".
We then add the two reserve amounts to that to get the minimum requested. This gives us a total for how much the user would like us to use at a minimum.
Using this number we then have to work out what is actually viable, ensuring we have at least enough room to work and do not exceed the total available and so froth.

So... given the minimum ask from above:
We limit that to the total VRAM that the system drivers tell us that you have, if you've been overly greedy 🙂 
We then do a little juggling where we work out the maximum total texture memory available (by asking opengl what is free and adding the amount we are already using to that number). This basically tells us how much RAM the driver has available given all other usage at that moment in time. 

If the user has asked for more than the total the GPU is saying it has available, then that is fine, the driver will try to expunge other things based on our demands (remember what I said about hints. Ideally you should avoid this it cause delays as the card has to swap stuff in and out when you have mutliple things competing for VRAM. So just set sensible limits.

so we take the larger of the two values (min requested by user, max_available) to determine the amount of texture memory we want. But we deduct the GPU reserve to ensure that there is room for the working space that we wanted.

This number is the Total texture memory the viewer will try to reserve.

Finally we then deduct the Cache reserve (the amount of space we want to keep for "working" textures) from this number, to give us the amount that we are allowed to use for "resting textures"

 

So.... ultimately these are advanced options and "(ab)use with caution" should be stamped on them. But so long as you are sensible and not trying to allocate all of the card on the misguided assumption that the rest of the system will not want any, you should be fine.

Work out how much of you  card you'd like to allow FS to use. this value is what you set the Minimum slider to. (M)
Work out how much of the total VRAM you'd like the viewer to keep for active work, this is the physical reserve (R)
Work out how much of total VRAM you'd like to hold back for the active textures in the scene. This goes into the Additional Texture Memory reserve. (T)

I would advise that M + R + T should be comfortably less than the full VRAM but you can experiment and see how it works.

Additional observation.

You have the decode concurrency set to 1, is there any reason for this? You are forcing the viewer to use a single thread for all texture decoding, on a machine like yours that is a significant barrier to performance and I would generally only ever suggest that for rally old machines that have just a couple of cores.

Setting the concurrency to zero will allow the viewer to use as many cores as it wants when decoding textures, what this means is that the scene should be grey for less time when you arrive as it will be able to unpack multiple textures at once instead of one at a time. (all of that happens on the CPU btw and is independent of the GPU parameters)

Caveat:

The above is written based on the actual code in Friestorm. However, I was not the dev that wrote those lines and it's 2am...so "best endeavours" applies.

Hope this helps.

[Jackson Redstar]

thank you both for replying 

I should have clarified when I have shaders and shadows on all my other programs are shut down except for OBS,  other wise my daily use is shaders and shadows off

@Beq Janus thanks for that very detailed explanation - the thing about decode concurrency - your explanation should be in the FS tips for that setting  - in FS it just says 0=Auto, 1=Synchronous and 2+=User specified 0 or 1 are recommended

[Beq Janus]

6 hours ago, Jackson Redstar said:

0=Auto, 1=Synchronous and 2+=User specified 0 or 1 are recommended

Good feedback, thank you. Synchronous is probably too technical for that tip and I suspect is my fault. Synchronous in this case meaning it happens on the same thread, interleaved with other things. As opposed to asynchronous meaning happening in parallel. Coders should not be allowed to write tooltips 😉 

[Jackson Redstar]

22 minutes ago, Beq Janus said:

 Coders should not be allowed to write tooltips 😉 

I worked in IT for years as a User Interface Designer, We also said the same thing about coders when it cam to them designing User Interfaces LOL

[Rachel1206]

On 4/26/2022 at 8:57 PM, Rachel1206 said:

Assuming you do run any other VRAM heavy software at the same time as your viewer, you should not get any problems.

Realized i forgot a NOT! Advice meaningless without the not... ::facepalm::

Assuming you do NOT run any other VRAM heavy software at the same time as your viewer, you should not get any problems.