fix(agc): accept disabled conservative rasterization with uncertainty-region bits

[EdouardSence]

Depends on #1915. Only the last commit, ab09a0a, is this PR; the first three are #1915's (its head af9e60b).

What

Ratchet & Clank: Rift Apart (PPSA01474) writes PA_SC_CONSERVATIVE_RASTERIZATION_CNTL = 0xe6000 on its first draws. Decoded with the field shifts in the kernel's gc_10_3_0_sh_mask.h:

Bits	Field	Value
0	OVER_RAST_ENABLE	0
5	UNDER_RAST_ENABLE	0
13, 14	OVERRIDE_{OVER,UNDER}_RAST_INNER_TO_NORMAL	1, 1
17:16	UNCERTAINTY_REGION_MODE	2
18, 19	OUTER_ / INNER_UNCERTAINTY_EDGERULE_OVERRIDE	1, 1

Both rasterization enables are clear, as in libSceAgc's 0x6000. On top of #1915's disabled mask (0x00106000), this also accepts bits 19:16, the uncertainty-region mode and its two edge-rule overrides:

• With either enable set, anything other than 0x6001 is still rejected. 0xe6001 and 0xe6020 are rejected.
• It is the narrow shape discussed on fix(agc): accept RADV's disabled conservative rasterization and out-of-order watermark #1915.

I have no source that says these fields do nothing when both enables are clear. RADV never writes them; it sets PBB_UNCERTAINTY_REGION_ENABLE only for overestimation. So the TechnicalDebt entry records it as an assumption from the field names, not a measurement.

Tested

Linux (CachyOS, GCC), RX 9070 XT, RADV / Mesa 26.2.4.

• agc_driver_graphics: 0xe6000 decodes as disabled and is not rejected; 0xe6001 and 0xe6020 are still rejected. fix(agc): accept RADV's disabled conservative rasterization and out-of-order watermark #1915's cases are unchanged.
• tools/check_conventions.py passes.
• Ratchet & Clank: Rift Apart on main 43972e6, with feat(libkernel): implement mlock and munlock #1673, feat(libSceVideoOut): register the VRR status event and accept the VRR status call #1339, fix(agc): defer shaders that cannot be prepared at registration to their first use #1836, fix(agc): accept bound copies of a registered shader header that differ only in user_data #1837, fix(agc): skip registration-time preparation for unsupported shader types #1893, perf(recompiler): compute post-dominators visiting successors first #2105 and fix(libkernel): start the pthread object with the thread id #2184, plus a local placeholder for munlock:
  • Before this change, the run stops about 19 s in on PA_SC_CONSERVATIVE_RASTERIZATION_CNTL=0xe6000: only 0x6000 (off) and 0x6001 (overestimation) are supported.
  • After it, the same draws go through. The run stops a moment later on depth/stencil clear, copy, resummarize or decompress draws (DB_RENDER_CONTROL) is unsupported (register 0x0 = 0x00000001).
  • No frame has been presented yet, so I can't show a visual comparison. With both enables clear, the host pipeline is the same as for 0x6000: no conservative rasterization.

Checklist

• Based on current main; no other open PR implements the same functions
• 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 in TechnicalDebt
• 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: fix(agc): accept RADV's disabled conservative rasterization and out-of-order watermark #1915
• AI-assisted: yes. The investigation, code, tests and this description were written by Claude (Claude Code) on my machine.

🤖 Generated with Claude Code

[rmz-24]

Windows run: Windows 11 Pro 25H2 (10.0.26200.9457), RTX 5060 Ti (NVIDIA 617.42), MinGW-w64 GCC 15.2.0 (WinLibs r7), Release, -DANYPS5_ENABLE_SPIRV_TOOLS=ON, full build plus libs. 11cd1dc cherry-picked onto current main d70b899 (applies cleanly).

• agc_driver_graphics passes on NVIDIA, in addition to the RADV run in the description.
• Full ctest: 510/510.

AI-assisted: yes

[adriadam10]

Checked on Linux, main + this head: agc_driver_graphics and agc_driver_prepared_graphics pass, and the new rows fail without the change. 0xe6000 decodes as disabled; 0xe6001 and 0xe6020 are still rejected. The mask change is applied in both DecodeState and DrawRejection, and the TechnicalDebt entry states the assumption honestly. Merging.