[Amoenus]

What

Append the affected color/DCC/CMASK plane, address, byte count and sample count to the existing watched-memory, changed-generation and pending-write refusals. Every predicate and the existing message prefix remain unchanged; details are formatted only on failure. This does not enable resident writes or identify their writer.

The remaining stop is writes to a resident multisampled DCC target or its metadata are not implemented. Rush 2 (PPSA69423) and Wave Race 64 (PPSA69424) reach it with #5939 and the dispatch correction. The added detail makes subsequent reports distinguish which owned plane changed. Those title runs are the reporter's evidence; I have not reproduced them.

#5939 is merged; Depends on: none. Current head 4b674a72ba, directly on main 51cee90311b427529e2b9899b13de334ae90d856, remains two files,+30/-3. The rebase conflict was the current range predicate: it retains UnchangedSince(...) || !StoredOver(...) from #7132 exactly and adds only the existing diagnostic helper around it. Pending-write and watching predicates are also unchanged. This adds no resident-write capability. #7250 supplies that separate full-range fast-clear case, with our attributed validation linked in the follow-up comment.

No duplicate diagnostic found. #6669 changes CMASK decoding, including its existing seed-line overlap with the parent; this diagnostic does not change that seed or decoding. #6543 handles dispatch ordering separately.

Stack-overlap clarification

The previous stack included #5939. Since it landed, the current main diff contains only this diagnostic. #6215 changes resident ownership; this patch does not establish a functional dependency on it. Earlier applicability checks retain their original pins.

Game follow-up with submitted #6869 — 2026-10-17 UTC

Integration 4de205aa01 includes exact #6869 head 58ba8a987 on the previous main17 composition. A fresh RTX5080 run reaches the same initial loading screen and stops after41.654s, without a timeout or any button command; seven BMPs are retained. The executable, guest libc, three toolchain DLLs and other126 PRXs are byte-identical to the42.646s baseline. Only AGC differs. Protected original input/module and both original configuration hashes remain unchanged.

AGC graphics: writes to a resident multisampled DCC target or its metadata are not implemented (DCC range 0x40819f4000+0x87000, 8 samples)

This identifies the tracked DCC metadata range, at8 samples, as the first failed generation check. The preceding tracked color-range check passes at that call. It does not establish whether the metadata values changed, which writer invalidated the generation, or whether a valid full fast clear occurred. The existing fence error remains unexplained. No new menu/gameplay/FPS or capability-unblock claim.

The submitted diagnostic was absent from the previous contribution composition; it is now included. A temporary plane-label experiment at 1689c46a3 reproduced DCC invalidation in42.631s and is superseded by this existing PR; no duplicate PR is being prepared. At the exact new integration pin, Windows/Linux full relinker/libraries builds pass and seven focused GPU fixture processes pass:2x/4x/8x on each actual NVIDIA/AMD GPU plus available4x llvmpipe (max0.66s, no selected skips; Linux2x/8x excluded for unavailable attachment support). This is validation of the integration, not an execution of the unchanged standalone PR head. AI-assisted: Codex; author responsible.

Tested

Current head4b674a72ba / main51: full Release relinker/system-library and selected graphics/recorder/alpha-to-coverage builds pass on Windows11 Enterprise26200 (GCC15.2r7) and Ubuntu24.04 WSL2 (GCC13.3).

• AMD Radeon(TM) Graphics1002:13c0,32.0.21036.18: CPU DCC state plus2x/4x/8x DCC clear groups each pass3/3,12 fresh processes, no selected skips/timeouts. Actual device identity is verified. Khronos1.4.363 loading confirmed, no observed VUID/validation errors. Shader cache/pipeline journal disabled; driver caches uncontrolled.
• Linux/llvmpipe LLVM20.1.2 (Mesa25.2.8): CPU state and supported4x clear each pass3/3,6 processes, no selected skips. Unsupported2x/8x are excluded from this selection; no Linux validation-layer claim.
• NVIDIA RTX5080 (10de:2c02,32.0.16.1062) is now free after the ordinary title replay: the same four groups pass3/3 at exact4b/main51,12 processes, actual identity verified, Khronos layer loaded and no observed VUIDs. Combined current matrix:24 Windows plus6 Linux processes, including CPU checks. Earlier65e controls retain their original pins in the linked historical report.
• Cppcheck2.20 then clang-tidy23.1.3 covers both changed TUs in37.042s, no parser/configuration failures. No selected clang-tidy finding. One existing Cppcheck advisory in recordCommands concerns conditional batch ownership: allocation and dereference take the same recorder == nullptr branch, and make_unique throws on failure. This is inspected advisory output, not a clean Cppcheck claim.
• Conventions and diff checks pass. No new game run, FPS or capability-unblock claim for this diagnostic rebase. The earlier title report above keeps its original integration pin.

cmake --build build --target agc_driver_graphics_tests agc_driver_alpha_to_coverage_tests
ctest --test-dir build -V -j1 --repeat until-fail:3 -R '^agc_driver_msaa_dcc_(state|clear_[248])$'

Checklist

• Based on current main; no other open PR implements this diagnostic (feat(agc): import uniform multisampled DCC fast clears #5939 is merged)
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none; diagnostic for the remaining refusal, not its implementation
• GPUs tested: NVIDIA GeForce RTX 5080, driver 610.62 / 32.0.16.1062; AMD Radeon Graphics, driver 32.0.21036.18; Windows 11 Enterprise 26200. Mesa 25.2.8 llvmpipe (LLVM 20.1.2), Ubuntu 24.04 WSL2. Current4b: NVIDIA, AMD and lavapipe as scoped above.
• AI-assisted: yes, Codex; author responsible

[github-actions]

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.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 7250	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp L368-369, L377-378

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 6628	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp
PR 6683	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp
PR 6808	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp
PR 6971	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp
PR 7800	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp
PR 7803	core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp

[jotitadev]

The description has NVIDIA on Windows and llvmpipe on Linux. This adds NVIDIA on native Linux.

Machine: NVIDIA GeForce RTX 3070, driver 595.99.02, Vulkan 1.4.329, Ubuntu 26.04, i7-8700, GCC 15.2, Release, BUILD_TESTING=ON. Head 67ec030c5 merged into main 452494439 (clean merge). Every runtime process logs Selected GPU name=NVIDIA GeForce RTX 3070.

• ^agc_driver_(msaa_dcc.*|alpha_to_coverage.*|dithered.*|undithered.*|graphics)$, 9 tests, -j1: 9/9 pass, 3 of 3 runs. That includes agc_driver_msaa_dcc_state and agc_driver_msaa_dcc_clear_2/_4/_8, which all run on this GPU (no skips, Multisampled DCC fast clear tests passed).
• I tried a negative control with main's Graphics/ sources and the PR's tests, but the tests do not compile against main (ColorTarget has no dccControl, no Graphics::MultisampledDccBytes), so I have no red run of my own. The description's controls cover that.

Not run: lavapipe (already in the description), Windows, AMD, the full suite.

GPUs tested: NVIDIA GeForce RTX 3070 (595.99.02), Ubuntu 26.04

Written with AI assistance (Claude Code). I ran the builds and tests above on my machine.

[milescoviello]

A current-main data point for this area. Linux, RTX 4070 Ti (NVIDIA 595.99.02), main bf20538, 40 s with scripted pad input, one run each:

• Rush 2 (PPSA69423) stops at 2 s, Wave Race 64 (PPSA69424) at 2 s and Ruffle (PPSA68091) at 11 s, all on multisampled DCC CMASK compression or register clear is not implemented. Before feat(agc): import uniform multisampled DCC fast clears #5939, Ruffle ran to the limit, and Rush 2 and Wave Race 64 stopped at once on DCC over a multisampled color target, which feat(agc): import uniform multisampled DCC fast clears #5939 replaced.
• In my earlier runs on feat(agc): import uniform multisampled DCC fast clears #5939's thread, adding fix(agc): take RADV's fill-memory kernel as a buffer fill #6543 ordered the fills first, and all three then reached writes to a resident multisampled DCC target or its metadata are not implemented. screamm saw the same for Ruffle on fix(agc): read a multisampled target's CMASK by its MSAA codes #6669.

Are you planning to implement the resident writes after this diagnostic? If so, I'm happy to run these three titles on your branch. If not, I'd rather ask before starting on it, since it builds directly on your #5939 design.

AI-assisted: yes (Claude Code)

[milescoviello]

A reproduction of the stop in the description, on Linux: Ubuntu 24.04, RTX 4070 Ti, NVIDIA 595.99.02, Release. Base is main e383833 with this PR (58ba8a9) and #6543 (2fc4fe5) merged on top, scripted pad input, 60 s per run.

App	Stops at	Message
Rush 2 (PPSA69423)	2 s	writes to a resident multisampled DCC target or its metadata are not implemented (DCC range 0x40062c1000+0x1000, 2 samples)
Wave Race 64 (PPSA69424)	2 s	same, (DCC range 0x40062c1000+0x1000, 2 samples)
Ruffle (PPSA68091)	10 s	same, (DCC range 0x4004606000+0x14000, 4 samples)

So the DCC metadata range is the plane that changed, in all three apps.

Without #6543, on plain main, all three stop earlier, at multisampled DCC CMASK compression or register clear is not implemented. A local print showed the import reads a uniform CMASK of 0x00, uniform DCC keys of 0x00 and zero clear words. That fits the import running before the apps' CMASK clear lands, which #6543 orders.

With #6543 and #7132 (e040cb7) instead of this PR (the two conflict in MultisampleTarget.cpp), all three stop on the same refusal, without the range detail. So excluding neighboring stores doesn't clear this one.

AI-assisted: yes (Claude Code)

[Amoenus]

@milescoviello Thanks for identifying the DCC plane. Your #7250 now implements the full-range resident DCC fast-clear case; I will build on that work rather than duplicate it here. I independently validated its earlier head 257a47071 on RTX 5080 and AMD Radeon Graphics, with the supported lavapipe groups as well: test results and exact scope.

In our Sonic integration with #6543, that change removes this DCC stop and reaches the menu, opening movie and level-loading stage; the next recorded stop is #7260. This does not validate your three titles or arbitrary resident writes: partial fills, unsupported keys and color-memory writes remain refused. Thank you for the implementation and title testing. This PR remains diagnostic only.

AI-assisted: Codex; author responsible.

[adriadam10]

Checked that all three refusals go through requireDccRange with unchanged predicates and message prefixes, that the detail is formatted only on failure, and that the test pins the plane, address, byte count and sample count for the color, DCC and CMASK cases; merged.