* updateImageDecodePriority - Avoid Long Face Loop
To avoid running a long loop on thousands of faces, some textures were being set to a BOOST level to avoid the updateImageDecodePriority function entirely but this was causing many of them to never be deleted over the course of a user's travels.
Instead of relying on BOOST, this commit changes the logic of the texture channel loop such that the face loop will only run if the number of faces is below the threshold.
To do this, we move the face_count incrementing outside of the face loop into the channel loop and increment it using the getNumFaces function instead.
We then check the face_count against the maximum number of faces we want to check and if it exceeds the number we set the number of faces for the face loop to check down to zero.
This avoids branch prediction misses and the long face loop issue.
Later, if the face_count is above the threshold, we assign the virtual size to the maximum.
I personally believe the max_faces_to_check should be lower than 1024, but I left that value in for continuity. I use 64 faces as my max on my compiled version of the viewer without any noticeable issues for memory use.
* updateImageDecodePriority - Face Loop Increment Swap
Looks like compilers like knowing the incrementing in the for loop information for optimizations and parallelization.
Sorry for the tiny commit.
* updateImageDecodePriority - Suggested Cleanup
Remove trailing white-space.
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
* OpenGL 3.3 compatibility pass. Fix for FBO driven downscaling corrupting textures.
* Increase maximum texture bias, immediately scale down when textures are loaded higher resolution than desired
* #2590 Fix for some frame stalls on Intel Macs
- Use GL_NVX_gpu_memory_info when available
- Disable transparent water on Mid+ and lower
- Adjust GPU benchmark to better tell the truth
- Texture bias tune up
- viewer-private/#277 - Report foreground_time in viewer stats
* #2315 WIP -- Clean up deletion rules in texture list. Incidental decruft.
* Touch up assertions.
* Move mLastReferencedTimer to LLViewerMediaTexture since it's no longer used by LLViewerTexture
In a previous PR, I noted:
Note this change moves the calcPixelArea() call to the top BEFORE we user getPixelArea(). Either that call is entirely redundant (i.e. if calc was called earlier in the frame) or we were using the stale pixelArea (one frame behind). If the former is true then it might be faster to just do an AABB frustum check.
It turns out that by moving the calcPixelArea to the "correct place", we break the rezzing of particles which are then being downsampled as a result. Moving this back to the "incorrect" location undoes the immediate effect but this whole scenario may need to be re-examined.
This change removes the distance based bias (which is a large contributor to premature blurring) but adds a check using the importance factor to give some balance.
importance should be between 0 and 1 and is higher when the texture is facing the camera, lower when it is side on,
The unimportance setting defines the cutoff vaklue below which we'll consider the textures worth "down scaling" by the bias factor. The setting is inplace to allow us to play with this, 0.25 is current default.
Note this change moves the calcPixelArea() call to the top BEFORE we user getPixelArea(). Either that call is entirely redundant (i.e. if calc was called earlier in the frame) or we were using the stale pixelArea (one frame behind). If the former is true then it might be faster to just do an AABB frustum check.
* #1836 Texture memory usage overhaul. Much decrufting
- don't keep a copy of textures in system memory
- use GPU to downrez textures instead of reloading from cache
- use GPU to generate brightness/darkness bumpmaps
png_read_info triggered a PngError, LLAppViewer::frame() handled it
instead of LLPngWrapper::readPng, and since status didn't
change viewer tried to decode image again and again and again.
Ansariel Hiller