Jump to content

Firestorm Texture Memory Autodetection


Recommended Posts

34 minutes ago, NiranV Dean said:

The texture thrashing happens because the Viewer loads textures in different mipmap levels (think LOD's for textures)

Thanks, very interesting. Now I'll have to go away and read all about mipmaps!

Link to post
Share on other sites
3 hours ago, Mollymews said:

shows what I know ūüėŅ

i peeked in the llimagegl.cpp file, and yes mipmaps. I don't like mipmaps because blurry then not blurry then blurry again on the Linden viewer

Its not the fault of mipmaps, without mipmaps you'd either not load it at all or load it in full resolution at all times. Again, if you use full res textures debug you'll force what happens when there are no mipmaps, you'll see your precious 4gb filled faster than you can count to 3. Mipmaps are extremely important and are used everywhere in gaming to reduce texture memory usage, without them we would need much more than 4-8GB for the average game nowadays.

image.thumb.png.52b5b901f306af41ade3a2af5c2ad529.png

Here's your ordinary club scene with a couple avatars, full res textures enabled. 13.5GB texture memory usage total. My GPU only has 6GB.

Pretty sure the Viewer wants to die but it just can't.

Not even a GTX 20XX with 11GB could handle this.

image.png.ce8715f93e9beb4bf0fa1a62191bc8b7.png

Without full res textures we're looking at measly ~2gb. That's only ~15% of the usage of all textures being loaded at their full resolution.

Edited by NiranV Dean
  • Like 2
  • Thanks 2
Link to post
Share on other sites
5 hours ago, NiranV Dean said:

Its not the fault of mipmaps, without mipmaps you'd either not load it at all or load it in full resolution at all times. Again, if you use full res textures debug you'll force what happens when there are no mipmaps, you'll see your precious 4gb filled faster than you can count to 3. Mipmaps are extremely important and are used everywhere in gaming to reduce texture memory usage, without them we would need much more than 4-8GB for the average game nowadays.

i get that mipmaps like LOD for models are very important for all the reasons that you mention

my issue (why I don't use the Linden viewer more than I do) is that I have some outdoor kitsets: rocks, trees, plants, land forms, water, etc that come with highly detailed  1024 x 1024 textures. What happens is that when I stand on a rock or a landform or even a large flat prim and rotate my avatar, or when something moving comes into my camera view, then what I am standing on goes from high-level mipmap (not blurry) to low-level mipmap (blurry) and sometimes, but not always, high-level mipmap (not blurry) as more/less other things come into the camera view. And somettimes it never goes to the high-level mipmap unless I right-click on it. Is why I thought the pipeline uses some kind of progressive mode, which it does, just not in the way I thought

of course I can just not use them and use smaller textures. But I don't want too, when I can use a TPV that doesn't perform as badly as the Linden viewer does because lower GPU memory limiting

 

i have a question to help my understanding of these matters.  Are the mipmaps linearly created on the CPU and buffered/cached in computer RAM and then transferred from the buffer cache to the GPU on demand, and as the camera view (the interest list) changes then are the mipmaps no longer on the interest list discarded from the buffer cache. And then when the objects come back into view then are the mipmaps recreate again linearly ? 

I think this is correct, as when I rotate my camera really quickly then the objects previously behind me are grey (in the large texture case) until the textures render again. But would be good if you could confirm this. Or say No, that's not how it works and I would be good that, and good also if you could explain how its does work, in the same way as you have been helping me to understand how stuff actually works

a speculation. If the mipmaps are created linearly on the CPU then I wonder what if any performance gain might be gained if the compression was done with a CPU+GPU CUDA encoder

 

 

Link to post
Share on other sites
51 minutes ago, Mollymews said:

i have a question to help my understanding of these matters.  Are the mipmaps linearly created on the CPU and buffered/cached in computer RAM and then transferred from the buffer cache to the GPU on demand, and as the camera view (the interest list) changes then are the mipmaps no longer on the interest list discarded from the buffer cache. And then when the objects come back into view then are the mipmaps recreate again linearly ? 

I think this is correct, as when I rotate my camera really quickly then the objects previously behind me are grey (in the large texture case) until the textures render again. But would be good if you could confirm this. Or say No, that's not how it works and I would be good that, and good also if you could explain how its does work, in the same way as you have been helping me to understand how stuff actually works

My understanding is that the mips are stored in the file format itself, so they wouldn't need to be created from scratch on the fly, just loaded directly. (Difference being less processing time.)

  • Thanks 2
Link to post
Share on other sites
1 hour ago, Wulfie Reanimator said:

My understanding is that the mips are stored in the file format itself, so they wouldn't need to be created from scratch on the fly, just loaded directly. (Difference being less processing time.)

ah! ok

so it does use a progressive mode. Send to the GPU the most compressed image/mipmap then memory permitting  send the next level up and so on. Understanding this then I can see how it can stay blurry when we run out of memory

it probably doesn't help me when I wear lots of 1024 x 1024 textures on my avatar outfits. They can stay blurry as well sometimes

i am either a graphics developer's best friend or worst enemy. Maybe their frenemy. I can ruin their world just by being myself¬† ūüėł

Link to post
Share on other sites
15 hours ago, Wulfie Reanimator said:

My understanding is that the mips are stored in the file format itself, so they wouldn't need to be created from scratch on the fly, just loaded directly. (Difference being less processing time.)

 

16 hours ago, Mollymews said:

i have a question to help my understanding of these matters.  Are the mipmaps linearly created on the CPU and buffered/cached in computer RAM and then transferred from the buffer cache to the GPU on demand, and as the camera view (the interest list) changes then are the mipmaps no longer on the interest list discarded from the buffer cache. And then when the objects come back into view then are the mipmaps recreate again linearly ? 

As far as i can tell they are pre-created on the server, not as classical mimaps though, they actually seem to exist as downscaled version. At least that's my assumption from what the texture console shows. I haven't checked the code but i'd assume that technically speaking, creating mimaps once while decoding them is the best solution, that way you save bandwidth, space on the server and do it while the Viewer is busy and crippled anyway.

  • Thanks 1
Link to post
Share on other sites
  • 1 month later...
On 08/08/2020 at 19:13, Lyssa Greymoon said:

Parece que deu certo, alguma atualização deve ter corrigido. Não foi nada que eu fiz. Como mencionado por outra pessoa no outro thread, 1 GB é o maior cache de textura que você deve ser capaz de usar em um cartão de 2 GB.

Got it! Now it was very clear! I have 2gb of vram! I have to conform! Thank you!

Link to post
Share on other sites
On 10/08/2020 at 17:38, Willow Wilder said:

Esses limites são apenas para o Firestorm Viewer: 

Somente vers√Ķes de 64 bits. Esta configura√ß√£o √© limitada com base na VRAM dispon√≠vel com sua placa gr√°fica. √Č recomend√°vel aumentar o controle deslizante para usar o m√°ximo dispon√≠vel para evitar a distor√ß√£o da textura.

  • GPU 1 GB = at√© 768 MB
  • GPU 2 GB + = at√© 1024 MB
  • GPU 4 GB + = at√© 2.048 MB

Somente vers√Ķes de 32 bits. Esta configura√ß√£o √© limitada a um m√°ximo de 512 MB.

 

Got it! now it's clear! I have 2gb of vram on the video card! Unfortunately I have to conform! I thought there was something wrong with me having 2gb. But now I understood perfectly!

Link to post
Share on other sites
  • 4 weeks later...

Is it possible using the command line flag to set maximum texture memory higher than 2048?  I tried 4096 and didn't get an error, but also don't know where to look and see if it did anything.  I have a 8gb card, so theoretically I could load a lot more and potentially speed things up.

  • Haha 1
Link to post
Share on other sites

Dan, I'm going to point you to my signature line before continuing and make it rather clear: I do not generally answer any questions concerning anything done here in the forum when logged into Second Life, IMs of that nature go right into File 13.

Now with that in mind ... 

Read. The. Thread. Then do a search for more information.

Unless the only thing you are doing while using a Second Life Viewer is using the Viewer there really aren't all that many reasons whatsoever to dedicate much of the memory for it to textures. And only textures, mind.

In either event, others have covered this far better.

Perhaps that puts the reaction into perspective - a reaction that was given in lieu of having to bother to type up a response that will likely be ignored or hand waved away.

Yes, I am cynical and jaded on some topics and yes it comes out even more on topics that have been 'discussed' to death.

Link to post
Share on other sites
14 hours ago, Dan Oxbar said:

Is it possible using the command line flag to set maximum texture memory higher than 2048?  I tried 4096 and didn't get an error, but also don't know where to look and see if it did anything.  I have a 8gb card, so theoretically I could load a lot more and potentially speed things up.

No - maximum is 2 GB no matter how much VRAM you GPU has. An excellent alternative, if you have a modern newer GPU, is The Black Dragon Viewer by @NiranV Dean , read the information and understand the differences to the other viewers. With Black Dragon Viewer you can adjust usage of VRAM and break the 2 GB limitation.

20201016_black_dragoon_viewer.png.14800ebdd5aa66daa3e0aee98d825d8a.png

Remember lot of things contributes to texture trashing - simple adjustments like lowering draw distance often the best solution. And always leave room for the OS to have VRAM - with Windows 10 at least 512 Mb, to be safe 1 GB.

If you are into high end photographing or machinima, Black Dragon Viewer is second to none, simply the best.

Edited by Rachel1206
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...