Fix texel coordinate assignment #58
Merged
Conversation
This file contains 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
In operations with mismatching texel blocks, i.e. when compressing from a pixel texel into a packed form or exploding a packed form, the index generation would only run on 1024—the default chunk size—input and output texels at a time resulting in some fetch/write coordinates being corrupted to the 0th texel instead. More specifically, it would always run on at most the chunk size texels but when mismatched texels are being used that is the count of super blocks. There are more reads and write happening. Each individually is stacked into a 'super block' that is the least common multiple along each individual axis. For instance, packing pixels into a 1x8 binary bit texture would use 8 input texels, one output texel, for each such super block which is 8 pixels wide. This would result in everything except the first eighth of each super block, which are 8*1024 input pixels (across rows), being wrongly filled with information from the 0th texel in the upper left corner effectively duplicating that single pixels color information *a lot* in images larger than 1024 pixels.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In operations with mismatching texel blocks, i.e. when compressing from a pixel texel into a packed form or exploding a packed form, the index generation would only run on 1024—the default chunk size—input and output texels at a time resulting in some fetch/write coordinates being corrupted to the 0th texel instead.
More specifically, it would always run on at most the chunk size texels but when mismatched texels are being used that is the count of super blocks. There are more reads and write happening. Each individually is stacked into a 'super block' that is the least common multiple along each individual axis. For instance, packing pixels into a 1x8 binary bit texture would use 8 input texels, one output texel, for each such super block which is 8 pixels wide. This would result in everything except the first eighth of each super block, which are 8*1024 input pixels (across rows), being wrongly filled with information from the 0th texel in the upper left corner effectively duplicating that single pixels color information a lot in images larger than 1024 pixels.