Repository navigation
feat(shader): accept the glc, slc and dlc cache bits on flat, global and scratch - #495
Conversation
Progress report (00407df → 183a0f0)📈 GPU shader instructions: 92.28% (+4.12%, +48 implemented instructions) ✅ 48 implemented
|
|
Rebased on current main on top of the rebased #491 (no conflicts in this PR's own commit). FlatCacheBits, GlobalAtomics and D16Memory pass on RADV and lavapipe. |
a2e86db to
7866ac1
Compare
7866ac1 to
e6bc02a
Compare
|
Rebased on current main: the only Windows failure was |
|
Thanks. I reviewed only the last commit (e6bc02a); the #390 and #491 commits are patch-identical to those PRs. The change matches what MUBUF does: loads and stores get
The only issue is the stack. Each branch carries its own rebased copy of the base commits, so merging the heads in order conflicts: this PR on top of #390's head conflicts in |
flat_store_* and global_store_* decoded and translated, but a store whose
segment is not scratch was refused when the SPIR-V was emitted ("writable
FLAT/GLOBAL addresses require GPU ownership tracking").
Such a store now goes through the BDA page table like a store through a
GPU-selected V#: the write lookup needs Write permission, which only a
writable registered range imported in place has, and the written page is
noted for the host to mark GPU-written. Byte and short stores, and dword
stores to an address that is not dword aligned, are stored byte by byte.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
…and scratch Loads and stores with glc or dlc are coherent, as MUBUF already does; slc is a cache hint and changes no result. Atomics keep glc as the return bit. lds, segment 3 and scratch atomics still throw. Co-Authored-By: Claude <noreply@anthropic.com>
e6bc02a to
183a0f0
Compare
|
Rebased: this branch is now #491's new head (038ded6, which carries #390's patch as be866e4) plus only this commit, unchanged. #390 → #491 → this one merges cleanly at every step (checked with |
|
Gated on PPSA21564 on top of #491: no visual or FPS change. |
What
FLAT, GLOBAL and SCRATCH loads, stores and atomics now accept the
glc,slcanddlccache bits. Before this, the decoder threwunsupported FLAT modifiers or segmentfor any of them, exceptglcon atomics. Found by the modifier sweep over decoded opcodes: everyflat_*/global_*/scratch_*with any of the three bits throws onmain. Compilers emitglc dlcon coherent loads andslcon streaming stores, so these show up whenever a shader uses global memory.This follows what MUBUF/MTBUF already do (
bufferLoad/bufferStore):coherent = glc || dlc. The BDA read and write paths already turn that intoVolatileaccesses (BdaAccessMask).slcis a cache-streaming hint and changes no result. MUBUF ignores it the same way.glcstill selects the pre-op return.slc/dlcare hints there too, and the atomics are device-coherent anyway.lds, segment 3, scratch atomics.Encodings checked with
llvm-mc -mcpu=gfx1013 -show-encoding:dlcis word0 bit 12,glcbit 16,slcbit 17, and every combination assembles on loads, stores, atomics and scratch.Depends on #491 (integer flat/global atomics), which depends on #390 (DotDebian, stores through FLAT/GLOBAL addresses). Both commits are included here so the stores and atomics can be tested with the bits; only the last commit is this PR. Both PRs rewrite the same decoder condition.
Behaviour measured on HW
The test kernel ran on a Radeon 660M (gfx1035, same VMEM encoding as gfx1013) over 32 lanes of edge values plus random rows. It does
global_load_dwordwithglc,slc,dlcand all three;global_load_dwordx2 glc dlc;global_load_ubyte slcandglobal_load_sbyte glc dlc(sign extension);global_store_dword glc slc dlc;global_store_byte slc; returningglobal_atomic_add glc slc dlc; non-returningglobal_atomic_sub slc dlc; andflat_load/store/atomic_xorthrough a 64-bit VGPR address withglc/slc/dlcmixes. All 32 rows (16 results each) match a model where the bits change nothing. The returning atomic gives the pre-op value, and the non-returning one leaves its VGPRs alone.Tested
Arch Linux, RADV (Radeon 660M) plus lavapipe (local Mesa and the CI version, Ubuntu Mesa 25.2.8). New execution test
FlatCacheBitsruns the same kernel as the HW measurement on a guest block. 64 threads run as wave32 and wave64. It checks the 16 results per lane against the HW rows, the final 16 bytes per lane, and that nothing else in the 64 KiB block changes.Negative checks: the test fails if the bits still throw, if
slcdrops the atomic return, or if adlcstore is skipped.Full Release build plus
ctest: 177/178. The one failure,agc_driver_pixel_helper_lanes, also fails onmainon local RADV since #305.FlatCacheBitstakes ~105 s on CI's lavapipe (18 BDA instructions per dispatch, two dispatches; BDA lookups are slow there, as with FlatStore), and under a second on RADV.Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt.mdfiles or images added to the repository (attach them to this PR)