Cool VL Viewer forum

I have just installed a video card with 11Gb of memory. The viewer seems to detect that properly as demonstrated by:I know the recommendation is to only use at most half of this 11Gb but since it seems to be capped at 8Gb, I moved the slider all the way to the right. This results in:Now when I return to the config option the slider is set to 4096 (half of my clamped max). However, this seems to disagree with the Debug Setting: TextureMemory, which does show 8032. Given the differing values, I'm not really sure which value is correct here. I'm possibly in the minority which use Cool VL Viewer and have a card with this much memory. Might there be a bug in how the Debug Setting and the Preferences UI differ? Would the recommendation just be to put my configuration at 4096? Cheers.

This is not a bug, although the log messages are misleading and have been changed for next release to be clearer.

The first time getMaxVideoRamSetting() is called, it is with a flag telling it to return the recommended maximums, while the second time, it returns the adopted maximums.

Your problem here, is that your system RAM is insufficient for the viewer to exploit the 11Gb of VRAM your graphics card got !
Bear in mind that the viewer needs much more texture RAM than it needs VRAM; for a start, each texture is stored in both its compressed/encoded (j2c usually, but maybe png, tga, jpg, bmp too) and "raw" formats, as well as a scaled texture (depending on the texture LOD), then there are also OpenGL "bound" textures, etc.
You would need 32Gb of RAM for the viewer to be able to use 10+ GB of texture VRAM. Finally, you cannot use all the VRAM for textures: the viewer also needs frame buffers, vertex buffers, etc...

So, in your case, the viewer properly clamps the texture RAM to 8Gb (half your RAM), which roughly translates in 4Gb VRAM (this latter limit is not a "hard" one, and the actual amount of VRAM used will vary without control by the viewer that only caps the associated RAM usage to avoid going too far; the actual VRAM amount used depends heavily on your graphics card architecture and its driver implementation).

EDIT: I also clamped the frame buffers total size estimation to 512Mb (instead of just VRAM/4) for next release, which should prove more than enough (even for 8K screens) and will allow more VRAM to be used for textures in 4Gb+ video cards...

Ah, thanks for the information and looking at this. It's sad that my system RAM isn't sufficient to use the VRAM to its fullest. Maybe time to upgrade RAM as well.

So does the Preferences UI slider reflect what the viewer determines it will use vs the value saved in TextureMemory? It just seems odd that the slider (for me) has a max of 8032 (half my RAM) but no matter what I slide it too (> 4096), upon looking at that setting again it is right in the middle at 4096 but the value stored in TextureMemory can be higher.

I already explained that in my post above. Texture RAM clamped to half your system RAM, which translates into the preferences to 4Gb of VRAM for textures (5.5Gb for next release, thanks to the frame buffers amount clamping I added to it).

Sorry about not understanding. It's a bit early here for me and my coffee hasn't kicked in.

Thanks for making that change, Henri. I have verified the log message has changed and I believe I am getting the max I'm capable of now (I upgraded system RAM to 32Gb).

I think I found the 'cause' of what I am seeing regarding the settings slider though. The skin file panel_preferences_graphics.xml has a max of 4096 as seen here:So while I could slide it higher and have TextureMemory change and get stored, upon returning to the Preferences UI, that slider would be maxed out at 4096. I have created an override copy of the skin file and placed in my .secondlife/skins folders. This will allow me to see the proper value when I return to look at that setting.

These slider maximum and minimum values are already set from the code, so what you see in the xml file is just a default value that *will* get overridden anyway. Your xml override should therefore make strictly no difference and you can remove it now that the code got changed.

EDIT: in fact, you are right, there is apparently a race condition in the UI code causing the texture memory setting to be capped to the default slider max value while the latter value gets properly set to the detected actual maximum... I'll fix that for next release.

It's nice that you found that because I didn't really like what felt like just a hack to change the value in the skin file.