[fdfawef324]

What

A shader preparation transaction takes the process-wide writers lock on its first Read, Edit or Hold and keeps it until the outermost transaction ends (#3159). Read and Edit take the lock before they wait for the snapshot's background registration preparation (AwaitRegisteredPreparation).

sceAgcCreateInterpolantMapping resolves the pixel shader's ABI first, which takes the lock, and then resolves the rectangle ABI, which reads the vertex shader and waits for its registration preparation while holding the lock. sceAgcLinkShaders and sceAgcCreatePrimState wait the same way in ResolveGraphicsStagesAbi. While one such wait lasts, every other RegisterShader and every other ABI resolution in the process waits for the lock.

ShaderPreparationScope now takes the shaders it will resolve. AgcDriverBeginShaderPreparation_nid_postfix(shaders, count) calls Driver::SettleShaderPreparations, which looks up the registered snapshot of each named shader and waits for its registration preparation before the scope's transaction exists, so before it can take the lock. A preparation never becomes pending again once it has settled. If a header is replaced between the settle and the read, the new snapshot is awaited under the lock, as before.

• sceAgcCreateInterpolantMapping names the vertex and pixel shaders (the vertex shader only when there is a pixel shader). sceAgcLinkShaders names both. sceAgcCreatePrimState now opens a scope around its graphics ABI resolution and names the hull and vertex shaders.
• When nothing is pending, the settle only looks up the snapshots. A registration preparation that failed is rethrown when the scope starts instead of at the first read of that shader in the same call.
• Still awaited under the lock: programs that ResolveGraphicsStagesAbi finds by code address and not by header (another header registered for the same code, a tessellation local stage), and fragments linked earlier to the same vertex shader when a rect-list ABI is requested.

Related:

• perf(agc): resolve static shader ABIs on the background pool #2589 queues static ABI compiles on the pool and waits for a snapshot's ABI jobs before Read and Edit take the lock. It does not move the wait for the registration preparation (pending), which still runs after Hold, so the rectangle ABI read of the vertex shader still waits under the lock. The two merge without conflicts. With both, the settle also runs or waits for the named shaders' queued ABI jobs before the lock.
• fix(agc): prioritize demanded shader preparation #4404 moves a preparation that a caller waits for to the front of the pool queue. That shortens the wait but does not move it out of the lock. With both, the settle's wait is the one that gets prioritized. The two merge without conflicts.
• fix(agc): wait for queued registration preparations before accepting a submission #5007 waits for queued registration preparations in Driver::Submit, before a submission is accepted. That is a different path and does not involve the preparation lock. The two merge without conflicts.

Tested

• Resident Evil 4 (PPSA07411), Windows, integration build. Measured with a local counter per 10 s window. Before: the preparation lock was held 8 to 10 s of every 10 s, almost all of it waiting for registration preparations, and loader threads waited 13 to 45 s per 10 s to take it. After: held 0.4 to 2.6 s per 10 s, and nothing waited for a preparation under it. On its own, the title still shows its black boot screen after 10 minutes on a cold shader cache, because the loader threads now wait for compiles outside the lock instead.
• New test agc_driver_preparation_scope_settle (tests/execution/PreparationScopeSettle.cpp). It holds every registration pool thread, registers a vertex shader whose preparation is then queued, and starts sceAgcCreateInterpolantMapping for it on another thread. It then checks that another shader can be registered while that call waits.
  • Without the driver change it fails in 5 of 5 runs with a link waiting for a registration preparation blocked the registration of another shader.
  • With the change it passes in 10 of 10 runs, about 1.5 s each, and in 18 of 18 runs with six copies running at once.
  • With perf(agc): resolve static shader ABIs on the background pool #2589 or fix(agc): prioritize demanded shader preparation #4404 merged and the driver change removed, it fails the same way in 3 of 3 runs. With the change on top of either one, it passes.
• Windows Server 2025, MinGW-w64 GCC 15.2.0, Release with BUILD_TESTING=ON, rebased on main 637ade8:
  • ctest -R "^agc_|^guest_shader_link$" -j 6: 463 tests, no failures, 1 skipped (agc_driver_stencil_ref_export).
  • tools/check_test_registration.py and tools/check_conventions.py --base upstream/main pass.
• Not tested: Linux.

Checklist

• Based on current main; no other open PR implements the same functions (perf(agc): resolve static shader ABIs on the background pool #2589, fix(agc): prioritize demanded shader preparation #4404 and fix(agc): wait for queued registration preparations before accepting a submission #5007 are related; see above)
• 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
• Unblocks: none. PPSA07411 still loads slowly and next stops at per-pixel sample locations.
• GPUs tested: NVIDIA GeForce RTX 3060 12 GB, driver 591.86 (32.0.15.9186), Vulkan 1.4.325, Windows Server 2025 10.0.26100
• AI-assisted: yes

🤖 Generated with Claude Code

[xXPBSXx]

Windows test (MinGW GCC 15.2, Release, Windows 10, RTX 4080 SUPER). Built on main 2a2a3dc65 together with nine other open GPU PRs (their own commits applied, no merge commits; one further PR, #5024, conflicted with them and was left out), so only the tests that belong to this PR say something about it:

• tests/execution/PreparationScopeSettle.cpp, which ctest runs as agc_driver_preparation_scope_settle: 3 of 3 runs passed.

Not tested: no game run. The batch was built once, not per PR; nothing failed, so no bisect was needed.

AI-assisted (Claude Code).

[adriadam10]

Checked on Linux: build and scoped ctest (libSceAgc + libSceAgcDriver) pass, and agc_driver_preparation_scope_settle fails without the driver change and passes with it. agc_driver_tessellation segfaults here with and without this PR, so it is not caused by it. Windows run of the test confirmed by @xXPBSXx. Merging once the full Build is green.