[boykopovar]

What

All game shaders pass through Driver::RegisterShader during game initialization. Recompiling them at this stage would allow draw/dispatch to use precompiled SPIR-V without compiling shaders during gameplay.

The current recompiler embeds resource parameters into shader code, so resource changes require recompilation. Even without resource changes, the initial compilation still occurs just before rendering during gameplay. Original shaders read these parameters at runtime. Recompiled shaders must do the same: fixed code, with resources supplied separately.

Compiled artifacts are separated from invocation data, and RDNA-to-SPIR-V compilation runs during shader registration and static ABI preparation. Draw/dispatch require prepared artifacts and fail if missing. Pipeline specialization and direct access for CPU-resolvable buffers are partially implemented; specialization validation and serialization have been added. Vertex fetch restoration and image/sampler optimization remain incomplete.

If successful, this will eliminate the last fundamental source of performance overhead compared to a real PS5.

Tested

There's no noticeable performance improvement on Dreaming Sarah. This may be because shader recompilation has never been a significant feature in this game.

Checklist

• 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
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none

[adriadam10]

Is there anything I can do to help with this without getting in your way? One idea: before you remove the image/sampler specialization, a test-only PR on main with execution tests that pin results across T#/S# variations (formats, dst_sel, mip/array ranges, clamp/border modes, filters), so you can check the runtime-descriptor version against them. If you would rather have something else, or a separate piece of the remaining work, tell me which and I'll stay off the rest. #473 is on standby until this lands.

[boykopovar]

Don't worry about changes to the main branch interfering with my progress. Keep up the good work. If my idea works, I'll resolve the conflicts myself and adapt everything.

[adriadam10]

Thanks! Then I'll leave this area to you: no new PRs from me on moving shader compilation to registration or on resource specialization, since your approach replaces it. I'll keep working on the rest as before.

[boykopovar]

Regarding #473, it's still not worth making any architecture changes that don't align with shader recompilation at the registration stage.

[Celegans12]

Testing notes from PPSA26344 (Ghost of Yōtei v1.008) on the runtime buffer path, in case they help.

The pattern. Six compute shaders stop on main at GetBufferResource dword 0 is not a valid runtime value: 0x8000289300, 0x800022d100, 0x800028d800, 0x8000284e00, 0x80002a9600 and 0x80002a1f00.

• They read a table of 192-byte records through a V# at [SRT+0x1b8]+0x20, then use the V#s stored in each record (+0x00, +0x10, +0xa0, +0xb0).
• The record offset is either loop-carried (s48 * 0xc0) or taken from a tile-list entry.
• Accesses through those V#s: buffer_load_ushort / ubyte / dword / dwordx4 (idxen), buffer_load_format_x, buffer_load_format_d16_xyzw (about 128 per shader), s_buffer_load, and buffer_store_byte / _d16_hi (glc).
• On main, TakeGpuDescriptor routes a runtime V# to BDA only for 32-bit raw accesses, so the ushort load at pc 0x78c reaches GetHandle and throws.

Replay through this branch. I replayed the six captured requests through this branch's agc_shader_replay (531e76d), with the SRT and record memory reconstructed from values captured live. The replay needed a local test-only patch: req version 8 and memory injection.

• ResourceTracker accepts five of the six. The sixth (0x800022d100) stops earlier, at a VOP2 SDWA destination selector that feat(shader): accept every SDWA selector on v_mov_b32 #751 fixed on main, so a rebase covers it.

Two things showed up.

1. Module size.
   • word3 is not an immediate, so formattedDispatch inlines all 77 formats at every formatted access.
   • Each module that compiles is about 56.7-56.9M SPIR-V words (227 MB), with 256 OpSwitches of 77 cases and 1.36M blocks. The title's other shaders are 17k-273k words.
   • I did not try to build a pipeline from one.
   • One SPIR-V function per (format, components, d16) called from the switch, or a switch on the format class, would keep it bounded.
2. RuntimeImageMode (ResourceMaterializer.cpp:552) throws "image descriptor is incompatible with the static runtime image interface" for the placeholder T#s the title binds at P+0x84..0xe4.
   • These are 1x1 format-56 TYPE 9 (2D) T#s, sampled with image_sample_lz dim:3D.
   • With the captured memory, three of the five hit this. With those T#s nulled, all five recompile.

Not verified. The byte stores through these runtime V#s need write access in the BDA table. As far as I can see, AddressRanges (GuestBufferMemory.cpp:2306) grants it only to imported writable allocations or to ranges in writes, and the driver never sees a runtime V#'s range.

Context. At this point in the title the record table is empty (num_records 0, count 0), so the loop runs zero times on hardware. When the six dispatches are skipped, the title goes on to present frames. Happy to re-run these shaders with the title after a rebase.

[Celegans12]

Two things from Ghost of Yōtei (PPSA26344) for this branch: a registration check at cf2bf8e, and the sub-dword buffer stores behind most of its 1.3 fps.

I ran PrepareShader the way RegisterShader calls it (zero user data, code and header only) over the 126 compute programs the title dispatched in a run today: 103 prepare, 23 throw. Only ProcessShutdown is caught on the way out of sceAgcCreateShader, so I'd expect the 23 to stop the title at registration, though I haven't run it on this branch. 16 of them dispatch fine on our integration build.

1. Five need support main already has: the SDWA selectors from feat(shader): accept every SDWA selector on VOP2 integer ops #509 (not feat(shader): accept every SDWA selector on v_mov_b32 #751, as I wrote last time), the vcc global base from feat(shader): accept vcc as the scalar base address of global instructions #750 and the DPP16 row_share controls from feat(shader): implement the DPP16 row_share controls #660.
2. Seven hit "shader image heap capacity exceeded". Each runtime image joins the group of every mode it might take, so a sampled group gets 18-20 images (capacity 16) or a storage group 5-7 (capacity 4).
3. Eleven stop at a T# the tracker can't resolve, among them a waterfall (0x800037f200), a T#/S# behind a pointer in a record (0x8000333c00) and a loop over 0x1b8-byte records (0x80003cab00). Are these shapes planned here?
4. Seven modules exceed the id bound of 4,194,303: 0x8000261500 and five record-table shaders from before (9.97M-12.36M, still the 77-format inline), and 0x8000390600. 0x8000305900 prepares into a valid module; I haven't run it.

On main, the light-culling shader (0x800036e100) takes about 589 ms of GPU time per dispatch, nearly all in compare-exchange loops for its 8- and 16-bit format stores, each an atomic over PCIe on host-imported memory. Plain 8/16-bit stores through aliased views take 28 ms, and the boot logos go from 1.3 to 5.6 fps with identical frames. Here runtime V#s store single bytes, but this shader's V#s take the direct path, where writeBuffer still merges sub-dword fields with AtomicUpdate. I have a small PR for main ready (buffers_u8/buffers_u16 views; odd addresses and devices without 16-bit storage keep the loop). Should I open it to land first, for you to keep or port, or hold it for you to fold in?

Two smaller questions. 0x80001e5f00 stores to tables it reads: is the bindless storage table refusal meant to stay? And 0x80002c4500's S# is unnormalized with wrap, which #799 still refuses (2391 skipped dispatches), but all 26 dispatches I dumped sample inside its 1408x1408 T#, so a clamp-to-edge sampler with a deferred fault outside it would be exact. On #822 that flag would be a ResourceSpecialization bit, which goes away here. Would a PipelineSpecialization entry suit you, and which FaultReason value? #757 adds ImageTable = 8, this branch InvalidDescriptor = 8.

Details

• Rebase: 0x800022d100 (SDWA), 0x80001e5f00 (global_load_dword with vcc base, pc 0x4a9c), 0x80003b1700, 0x80003c5900, 0x80003dc800 (DPP).
• Heap: 0x8000253100, 0x8000265d00, 0x80002c4500, 0x80002e1b00, 0x8000368d00, 0x80003cc000, 0x80003cfa00.
• T#, others: 0x80001d5700, 0x80001fd400, 0x800024de00, 0x800027c200, 0x8000316900, 0x800031e600, 0x8000364b00, 0x80003aa700.
• 0x800036e100 here: 41 spec constants, 7716 OpAtomicCompareExchange.
• 0x80002c4500 S# 00008000 00fff000 05000000 00000000; u 0.5-719.5, v 96.5-1055.5.
• Sub-dword A/B, RTX 3080 Laptop, GPU and draw profiling on: 13-14 to 46-57 presents per 10 s, GPU busy per present ~686 to ~110 ms, 67 frame dumps pixel-identical. Offline replay: 578-593 to 29-31 ms, written buffers byte-identical. A plain read-modify-write loses bytes (tiles share dwords), so it needs real narrow stores. About 4.5M loops per dispatch (138 per group).