updateImageDecodePriority - Avoid Long Face Loop #4019
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Looks like compilers like knowing the incrementing in the for loop information for optimizations and parallelization. Sorry for the tiny commit.
|
Sorry for the additional small commit. I did not realize how much compilers like knowing when the incrementing value will increment. Reduces the number of instructions on GCC, most likely Clang as well, and might allow for parallelization. |
marchcat
reviewed
May 5, 2025
Remove trailing white-space. Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.