[Celegans12]

What

SINT storage images throw storage image descriptor uses an unsupported format, except write-only 32_SINT.

• Stores of 8- and 16-bit SINT components saturate (EmitFormatStoreComponent); 32-bit SINT formats store raw dwords, also with image_store_pck.
• adriadam10 measured these stores on RDNA2 (gfx1035): with DST_SEL X,Y,0,1 on the two-channel formats all 448 rows match. The PS5's gfx1013 is not measured.
• With X,Y,Z,W, gfx1035 writes channel 1 of a two-channel format from the W data slot; StoreTexel takes Y, as it does for UINT on main (TechnicalDebt).
• StorageTexture::StorageView binds a cached same-size UINT view; loads keep the sign-extending SINT view.
• Still throws: 8_SINT, 32_32_32_SINT, packed SINT formats (11_11_10, 10_11_11, 2_10_10_10, 10_10_10_2), D16 stores (zero-extended on main), image_store_pck of 8- and 16-bit components, and atomics other than 32-bit ones on 32_SINT and 64-bit ones on 32_32_SINT.
• PPSA26344 v1.008: with feat(agc): implement image and sampler tables indexed at runtime offsets #757-feat(agc): implement deferred faults for reads through null SRT pointers #759, the jump-flood shader 0x80003cab00 throws this message on its 16_SINT image.
• perf(agc): baseline shader recompilation on registration #639 also rewrites StoreTexel and the storage descriptor write; whichever lands second keeps the SINT saturation and StorageView. feat(agc): implement image and sampler tables indexed at runtime offsets #757-feat(agc): implement deferred faults for reads through null SRT pointers #759, feat(agc): implement image_load through image tables #920, feat(agc): implement 8 and 8_8 srgb image loads through unorm views #866, feat(agc): implement 8 srgb color targets through rgba8 srgb proxies #1058 and feat(agc): host import windows, least-recent eviction under the budget #290 edit the same functions and merge cleanly with this.

Tested

• Windows 11, MinGW-w64 GCC 15.2.0, based on main 878e6a6: configure -DBUILD_TESTING=ON, full build, --target libs, ctest:
• 388/388 tests pass (ctest --output-on-failure)
• Same build on lavapipe (Mesa 26.2.4 llvmpipe, 8-wide subgroups, VK_DRIVER_FILES): 387/387 pass; agc_driver_flat_store is left out there because it takes several minutes on Windows llvmpipe
• New agc_driver_image_store_sint: eight formats, dmask 0xf and 0x5, 24 edge values and X,Y,0,1 on two-channel formats, an image_load read-back, image_store_pck on the 32-bit formats, the title's store (dmask 0x1 glc, DST_SEL X,1,1,1) and six throws; fails on main with the message above.
• Not tested: PPSA26344 with this change, PPSA21564 and Dreaming Sarah, Linux (CI), console behaviour.

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: none
• AI-assisted: yes

[adriadam10]

Measured on the HW oracle (gfx1035, raw image_store + read-back): 8 formats × dmask 0xf/0x5 × 24 edge values. With X,Y,0,1 selectors on the two-channel formats all 448 rows match this PR (per-component saturation, zero for components outside dmask, raw 32-bit). Build + ctest green, and the new test fails without the change. Three things before merging:

• ImageStoreSint.cpp:34/:289: the test stores to 8_8, 16_16 and 32_32 SINT with DST_SEL X,Y,Z,W (0xfac). With that T#, the hardware writes channel 1 of a two-channel format from the W data slot, not from Y. dmask 0xf of (0x11, 0x22, 0x33, 0x44) stores (0x11, 0x44), and dmask 0x3 stores (0x11, 0). So the dmask 0xf rows pin values the console doesn't produce (86 rows differ on 8_8/16_16/32_32). StoreTexel behaves the same for UINT on main, so it predates this PR. Please use X,Y,0,1 (0x22c) for the two-channel formats so the test only pins what the hardware does. The W-slot aliasing can go to TechnicalDebt or a separate PR.
• TechnicalDebt.md:146: image stores are measured now. Either drop the line or say that they were measured on RDNA2 (gfx1035).
• ShaderResources.cpp:1060 conflicts with main after #896 (Atomic64View). Please rebase and keep both branches, as you noted in the description.

[Celegans12]

Thanks for measuring the stores on gfx1035. The 448 matching rows are exactly what the PR was missing, and I hadn't noticed that with X,Y,Z,W the hardware writes channel 1 from the W slot.

I've force-pushed 6e34e86 with all three points:

• The 8_8, 16_16 and 32_32 SINT cases now use X,Y,0,1 (0x22c) in the store loop, the image_load read-back and the 32_32 image_store_pck row, so the test only pins what the hardware does. The expected values didn't need to change.
• The W-slot behaviour is its own TechnicalDebt line, since it predates this PR and StoreTexel does the same for UINT. The image-store line now says the saturation was measured on RDNA2 (gfx1035) and that the PS5's gfx1013 isn't measured.
• It's rebased onto main after feat(recompiler): implement 64-bit image atomics #896, keeping both branches in buildComplete: the storage descriptor write picks Atomic64View, then AtomicView, then StorageView.

[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
#1017	docs/dev/TechnicalDebt.md L204

[adriadam10]

Thanks for the quick turnaround. Checked 6e34e86 on RADV (gfx1035 oracle for the hardware side):

• Oracle: the 448 image_store rows (8 formats × dmask 0xf/0x5 × 24 edge values, X,Y,0,1 on two-channel formats) and the test's other forms (dmask 0x1 glc with X,1,1,1 on 16_SINT, image_store_pck dmask 0x3 on 32/32_32/32_32_32_32_SINT, 128 rows) all match.
• Build + ctest green (393/393), and agc_driver_image_store_sint fails without the change.
• TechnicalDebt lines and the rebase onto #896 look right.

Merging.