Skip to content

Conversation

slipher
Copy link
Member

@slipher slipher commented Sep 18, 2025

Depends on #1813.

Implement a code path for sampling u_DepthMap in 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 implement TextureBarrier, in order to prevent texture feedback loops. Behavior is controlled by r_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-pit I 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. Anyway set r_copyDepthBuffer 2 from this PR fixes those artifacts for me.

unvanquished_2025-09-05_142446_000

Things to do:

  • Check if I'm copying the depth buffer in the best way. Is there a depth-only format I should be using instead of the depth + stencil?
  • Disable depth buffer copy if r_depthShaders (incompatible debug cvar) is disabled
  • Ask @illwieckz to assess the performance of this on low-end cards
  • Determine which hardware/driver combinations still have issues with reading the depth buffer despite implementing texture barrier. (This could go in another PR)
  • Maybe skip texture barriers if the duplicated depth buffer is used?

@VReaperV
Copy link
Contributor

  • Check if I'm copying the depth buffer in the best way. Is there a depth-only format I should be using instead of the depth + stencil?

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.
@slipher slipher force-pushed the depthcopy branch 2 times, most recently from 5473f57 to 8d943fa Compare September 27, 2025 22:15
If the texture barrier GL extension is enabled, make a read-only copy of
the depth buffer to use for u_DepthMap sampling, thereby avoiding
texture feedback loops in another way. Configurable by setting
r_readonlyDepthBuffer 0 (skip the copy even if there is no texture
barrier - useful for low-performance systems) or r_readonlyDepthBuffer 2
(always make the copy - useful for testing that code path).

Fixes DaemonEngine#1783 (broken depth fade on Apple Silicon).
@slipher slipher marked this pull request as ready for review September 27, 2025 22:52
@slipher
Copy link
Member Author

slipher commented Sep 27, 2025

This is ready. On my worst GPU, the Intel UHD 630, I registered about a 10% performance drop (53 -> 48 FPS). So we definitely want to disable it in low presets.

@illwieckz
Copy link
Member

On an ATI X550 I only seen a 1 fps difference, so I guess it depends on the driver.

I'll add the cvar to the presets indeed.

@slipher
Copy link
Member Author

slipher commented Sep 27, 2025

This GPU can have texture barrier according to reports. So make sure your comparison is between r_readonlyDepthBuffer 0 and r_readonlyDepthBuffer 2.

@illwieckz
Copy link
Member

See Unvanquished/Unvanquished#3430 for the game presets/ui menu:

Now that I think about it, it's probably better to do instead:

  • 0: disabled
  • 1: enabled
  • 2: auto.

Not only because 0/1 is not bad for disabled/enabled, and because then the higher number (2) would “bring the best” and usually people look for the higher number for getting the best. I noticed that in the menu I ordered 1, 2 ,0 to order it that way (from top to bottom):

  • When necessary (recommended),
  • Enabled (slower),
  • Disabled (faster, buggy).

I felt it was better for the UI where we make the effort to put the “best” at the top.

@illwieckz
Copy link
Member

This GPU can have texture barrier according to reports. So make sure your comparison is between r_readonlyDepthBuffer 0 and r_readonlyDepthBuffer 2.

Same missing 1 fps when forcing the read only as well.

@slipher
Copy link
Member Author

slipher commented Sep 28, 2025

Now that I think about it, it's probably better to do instead:

* `0`:  disabled

* `1`: enabled

* `2`: auto.

2 is mostly intended for debugging, so in the UI I would put a checkbox which would work well with the current 0/1 values.

@illwieckz
Copy link
Member

OK, it makes sense that way then.

I updated my PR to use a checkbox instead.

Copy link
Member

@illwieckz illwieckz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@illwieckz
Copy link
Member

Merging this for the release.

@illwieckz illwieckz merged commit 386d693 into DaemonEngine:master Sep 28, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Depth fade broken on Apple Silicon
3 participants