Copy depth texture to avoid texture feedback loops #1814
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
We don't use renderbuffers. The renderbuffer size limit does not apply to an FBO.
Replace GL_FRAMEBUFFER with GL_DRAW_FRAMEBUFFER everywhere. Binding GL_FRAMEBUFFER to x is defined as binding GL_DRAW_FRAMEBUFFER to x then binding GL_READ_FRAMEBUFFER to x. Currently we only use the DRAW aspect. The double binding can be a nuisance when adding functionality (blit) that needs the read aspect.
Co-Authored-By: VReaperV <[email protected]>
Depth and stencil buffers are always implemented as part of one render target. |
slipher
added a commit
to slipher/Daemon
that referenced
this pull request
Sep 19, 2025
Since it's about to be used more times. I named it like PrepareForSamplingDepthMap instead of something about texture barrier, because I may want to add more stuff in for DaemonEngine#1814 where there is the possibility to use a copy of the depth texture instead. Also attempt to track depth buffer dirtiness with material system.
slipher
added a commit
to slipher/Daemon
that referenced
this pull request
Sep 19, 2025
Since it's about to be used more times. I named it like PrepareForSamplingDepthMap instead of something about texture barrier, because I may want to add more stuff in for DaemonEngine#1814 where there is the possibility to use a copy of the depth texture instead. Also, always mark depth buffer dirtiness with material system.
slipher
added a commit
that referenced
this pull request
Sep 20, 2025
Since it's about to be used more times. I named it like PrepareForSamplingDepthMap instead of something about texture barrier, because I may want to add more stuff in for #1814 where there is the possibility to use a copy of the depth texture instead. Also, always mark depth buffer dirtiness with material system.
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.
Depends on #1813.
Implement a code path for sampling
u_DepthMapin shaders from a separate copy of the depth texture, instead of the same one that is attached to the rendering FBO. By default, this will be enabled if the driver does not implementTextureBarrier, in order to prevent texture feedback loops. Behavior is controlled byr_copyDepthBuffer. This is meant to fix #1783. Seems to work on my Mac system.Also I keep having some issues with SSAO + bindless textures on a Mesa + AMD setup. In a game with map
survival-pitI got the SSAO artifacts as shown below. (Same ones I used to get with dummygame. I still got those even after #1731 which I though would fix them but didn't, but they may have gone away after a Mesa update.) I can't reproduce the artifacts in a local game but if I play a demo recorded from an online game, I get the artifacts the whole time. Anywayset r_copyDepthBuffer 2from this PR fixes those artifacts for me.Things to do:
r_depthShaders(incompatible debug cvar) is disabled