Repository navigation
fix(agc): storage access to a depth surface's stencil plane through its stencil aspect - #2325
Closed
fisherjoey wants to merge 9 commits into
Closed
fisherjoey wants to merge 9 commits into
fisherjoey wants to merge 9 commits into
Conversation
Titles fast-clear a depth surface by filling its HTILE with ZMASK 0 (DMA_DATA immediate fills or the buffer-fill kernel) instead of drawing. Depth surfaces were only cleared when they were made, so every later frame kept the previous frame's depth and stencil and most draws failed the depth test. The depth target now records DB_HTILE_DATA_BASE. A uniform fill whose ZMASK is 0 and which covers a surface's HTILE marks the surface cleared; its next use as a target or a texture clears it to DB_DEPTH_CLEAR and DB_STENCIL_CLEAR. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ds; HTILE only with TILE_SURFACE_ENABLE A fill over a depth surface's whole HTILE fast-clears the depth when ZMask is 0 and, when the HTILE holds the stencil state (TILE_STENCIL_DISABLE clear), the stencil when SMem is 0; a fill writing an aspect's fields otherwise cancels its pending clear. DB_HTILE_DATA_BASE is taken only with DB_Z_INFO.TILE_SURFACE_ENABLE. Tests cover the decode and HtileFillClears/HtileFillCovers. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…erage and clear value as inferred Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A whole-HTILE fill of ZMask 0 clears the depth to DB_DEPTH_CLEAR at the next draw; a fill shorter than the HTILE and an expanded fill (ZMask 0xf) clear nothing. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…el DCBs; a CPU-stored fill clears too agc_driver_depth_fast_clear_submit submits the fills the title uses (a DMA_DATA immediate fill and the fill kernel's dispatch) over the HTILE and checks the next depth-tested draw; a depth-only fill over an HTILE with stencil keeps the stencil (a stencil-tested draw). The depth metadata note now also follows the CPU fallback of a fill the device could not store. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sampling a depth surface as a 2D array, a cube or its R16_UINT integer bits copies its depth planes into a per-use image: each slice a depth surface holds comes from that surface's plane, any other slice from guest memory. A storage image over a depth surface's memory takes the depth plane's bits when it is looked up, and the depth surface takes the image's bits back at its next use. Depth surfaces can be transfer sources; textures copied per use never serve a draw template or the stage-A fast path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…owing; seeding applies a pending fast clear A storage T# at a depth surface's stencil address matched DepthSurfaceAt, but nothing seeds a storage image from the stencil aspect or takes its writes back, so a store there landed in an image the depth surface never read (PPSA26344's deferred-decal pass ORs 0x04 into the stencil this way). It throws as on main until the stencil plane is handled. SeedStorageFromDepth now applies a pending HTILE fast clear before taking writes and copying, as the sampled paths do.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ts stencil aspect
9 tasks done
This was referenced Oct 9, 2026
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
|
Contributor
|
Tested on Linux (CachyOS x86_64, Intel RPL-S iGPU / Mesa 26.3.0-devel / Vulkan 1.4.363, GCC 16.2.1) at
LGTM! |
Contributor
Author
|
I missed #2076 when I opened this. @jdmagic opened it nine hours before this one, and it does the same thing: both stack on #425 and route a storage T# at a depth surface's stencil plane through #2076 came first, so that's the one to review. This PR adds two things on top of it:
I can't open a follow-up PR on top of #2076 (new PRs from me are closed by intake for now), so I'm closing this one. Both parts are in commit 598f788 on fisherjoey/AnyPS5 AI-assisted: yes |
Merged
9 tasks done
This was referenced Oct 9, 2026
Merged
9 tasks done
jdmagic
pushed a commit
to jdmagic/AnyPS5
that referenced
this pull request
Oct 11, 2026
A stencil draw fills a D32S8 surface's stencil plane; image_load through an 8-bit T# at the stencil address reads it back, and image_store over the whole plane replaces it, which a later stencil test sees. Cherry-picked from 598f788 (closed boykopovar#2325). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
11 tasks done
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
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.
What
Storage-image access to a depth surface's stencil plane. #425 handles the depth plane through
Transferand a writer. This change extends that model to the stencil aspect:Transfertakes an aspect. The stencil plane needs an 8-bit storage format and a single layer; anything else still throws.DepthSurfacekeeps a stencil writer next to the depth one, andTakeWritesandApplyFastClearhandle both planes.SeedStorageFromStencilseeds it, andcachedStorageTexturecalls it instead of throwing.Depends on #425.
The diff shows #425's commits until it merges, since GitHub can't stack a PR on a branch in another fork. Review 598f788 only. #1684 and #1842 also add stencil storage, against
mainand in a different way, so only one of the two approaches should land.Tested
Linux (Nobara 44, kernel 7.2), GCC 16, RTX 5070 Ti with NVIDIA 595.91.07, and RADV.
agc_driver_stencil_plane_storage: a draw writes stencil 0x5a, a computeimage_loadmust return 0x5a, then a computeimage_storeof 42 must make stencil EQUAL 42 pass everywhere and EQUAL 0x5a nowhere. Fails on feat(agc): depth planes sampled as 2D arrays, cubes and integer views #425's head withstorage access to a depth surface's stencil plane is not implemented; passes with this change. feat(agc): depth planes sampled as 2D arrays, cubes and integer views #425'sagc_driver_depth_fast_cleartests pass.ctest -R agc_ -j1: 227 of 227 on the RTX 5070 Ti and 227 of 227 on RADV (Ryzen 5 7600X iGPU, Mesa 26.2.1).tools/check_conventions.py --base 62b1e552: passes.Checklist