[BUG-225194] Reduce 32 bit viewer memory consumption

[sl-service-account]

How would you like the feature to work?

Set MAX_IMAGE_SIZE_DEFAULT to 512 for 32bit viewers&inworld images (1024 for 64 bit), with exception of LLGLTexture, huds, selected images, UI, e t c... Intent is to make processTextureStats() increase discard level

Why is this feature important to you? How would it benefit the community?

Quality and weight of SL content growth up constantly, but memory of 32 bit machines stays same. This should alleviate issue a bit by reducing quality of largest textures, but if you are running at 32 bit hardware you shouldn't expect quality in the first place.

P.S. I know it is not the best solution, but 32 bit viewer crashrates are constantly growing and this seems to be good enough option to try (in BUG-225156 textures take around half Gb of memory). Ideally we should modify impostors to work with lods better, make avatars switch lods e t c. but with missing lower lods for meshes there is very little we can do.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-225194 | | Summary | Reduce 32 bit viewer memory consumption | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | AndreyK ProductEngine (andreyk.productengine) | | Created at | 2018-08-01T15:50:41Z | | Updated at | 2018-08-09T17:03:20Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2018-08-01T13:17:33.351-0500', 'How would you like the feature to work?': 'Set MAX_IMAGE_SIZE_DEFAULT to 512 for 32bit viewers&inworld images (1024 for 64 bit), with exception of huds, selected images, UI, e t c...', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "Quality and weight of SL content growth up constantly, but memory of 32 bit machines stays same. This should alleviate issue a bit by reducing quality of largest textures, but if you are running at 32 bit hardware you shouldn't expect quality in the first place.\r\n\r\nP.S. I know it is not the best solution, but 32 bit viewer crashrates are constantly growing and this seems to be good enough otion to try. Ideally we should modify impostors to work with lods better, make avatars switch lods e t c. but with missing lower lods for meshes there is very little we can do.", } ```

[sl-service-account]

Whirly Fizzle commented at 2018-08-01T18:17:33Z

How about enabling "Enable texture compression" (Prefs -> Graphics -> Advanced) by default on all the 32bit builds?

[sl-service-account]

Ansariel Hiller commented at 2018-08-01T18:17:50Z, updated at 2018-08-01T18:19:20Z

How would that actually help? Texture memory is limited to 384 MB already anyway. Or is the crash happening during texture loading before LOD bias is kicking in, reducing the amount of used memory? Isn't the actual problem the number of meshes with high number of vertices?

Of course it would also help if textures aren't also held in system memory but would be directly loaded in GPU memory. But since we are still stuck with 2004 OpenGL tech for most parts of the viewer...

[sl-service-account]

AndreyK ProductEngine commented at 2018-08-01T18:39:42Z, updated at 2018-08-01T18:54:16Z

How about enabling "Enable texture compression" I think, it is not going to work at half of the 32 bit hardware, it requires opengl 3.0. Most crashes are at Intel(R) HD Graphics with OpenGl 2.1 and there are even older versions around.

How would that actually help? Texture memory is limited to 384 MB already anyway. I think '384' is Gl memory or buffer. In reality textures take a lot more. For instance each texture additionally store dowloaded encoded image and decoded 'raw' image, that are in memory. MAX_IMAGE_SIZE_DEFAULT (llgltexture will have to use separate value, or stats will have to use some kind of discard_size) will affect discard level, so viewer will atempt not to download texture past 512px (processTextureStats())

Isn't the actual problem the number of meshes with high number of vertices? Yes, it is part of the issue, but it won't be resolved soon. I think it requires policy changes for LODs at minimum->avatar LODs fix->impostors improvement. Or server changes to provide less of a mesh when other LODs are not needed (not sure if it is a good idea, but something along those lines...). And textures (not just Gl, but image list as well) in BUG-225156 take almost third of all content related memory.

[sl-service-account]

Ansariel Hiller commented at 2018-08-01T18:58:59Z

With the current texture limit of 384 MB (that is what you actually get if you set 512 MB) in preferences, the viewer stores up to 768 MB of textures in system memory. That value might of course be temporarily higher if the viewer is loading textures until the LOD bias kicks in to reduce texture LOD (and size). In the end that hasn't changed for years, so I'm not quite convinced simply loading/requesting lower LOD textures will help. Because in the places textures are a problem, there are most likely so many textures that the effect will easily compensated by the higher number of textures being loaded.

[sl-service-account]

AndreyK ProductEngine commented at 2018-08-02T00:05:46Z, updated at 2018-08-02T00:07:25Z

With the current texture limit of 384 MB There is a limit on disk cashing, gl textures e t c, there is no limit on textures being in operational memory of fetcher, list(mImageList) and no control over raw texture allocation.

That value might of course be temporarily higher if the viewer is loading textures until the LOD bias kicks in to reduce texture LOD (and size). As it is viewer starts from lower 'LOD' (discard actually) resulting in lower size and loads more and more of the texture over time. Unless it is something like hud, UI or textures from previous session, viewer won't request full texture from the start, it will attempt to do partial downloads (both from cache and network).

Because in the places textures are a problem, there are most likely so many textures that the effect will easily compensated by the higher number of textures being loaded. Some places are full of max sized textures, for 32 bit viewer it means ability to load up to 4 times more textures (obviously will never happen, but I suspect that there will be noticeable improvement). Obviously such change requires testing.