Fix VertexBufferHolder breaking with cached PoseStack entries #5778
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
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.
When creating buffered jobs,
VertexBufferHolderstores the position matrix contained in the last entry of thePoseStackin order to use it later. However, the block entity renderer pops that entry off the PoseStack shortly after. In vanilla, this does not cause a problem, as PoseStacks allocate fresh entries each time. However, some performance mods (e.g. Sodium) might cache PoseStack entries to curb the allocation rate in scenes with lots of block entities. This causes issues with IE as the sameMatrix4finstance ends up being reused many times, causing all block entities usingVertexBufferHolderto render at the same location (video provided by the user who experienced the problem).It's debatable whether this is a bug in IE, since the code works correctly if mods provide the same semantics as vanilla. Sodium's input on the issue was that it is undefined behavior in graphics programming to expect a matrix reference to be valid after popping it off the stack. I chose to fix the issue in Embeddium by disabling the problematic optimization, since I personally believe vanilla semantics have to be preserved for compatibility, but I'm providing this PR to also fix the issue on IE's end.