[adriadam10]

What

Test only, no recompiler change. Adds an execution test for the 8 flat_load_* and 8 global_load_* opcodes (ubyte, sbyte, ushort, sshort, dword, dwordx2, dwordx3, dwordx4). No execution test covered them on main: D16Memory covers only the D16 forms, and the cache-bit forms are in #495. The test found no bug.

It runs two compute shaders on 32 lanes over a guest block. Each lane loads from its own address, and checks 16 result dwords against values measured on hardware. The rows cover:

• global with an SGPR base (v32, s[8:9]) and with a 64-bit VGPR address (v[34:35], off)
• global offsets at both ends of the signed 12-bit range (-2048, 2047) and small negative ones (-1, -3, -6)
• flat offsets up to the 11-bit unsigned maximum (2047)
• addresses not aligned to the access size (odd ushort, unaligned dword to dwordx4)
• sign and zero extension of bytes and shorts with the top bit set
• lanes with EXEC off, which must keep their old VGPR values

Encodings come from llvm-mc -mcpu=gfx1013 -show-encoding.

Behaviour measured on HW

The same two kernels ran on a Radeon 660M (gfx1035, same FLAT encoding as gfx1013). All 64 rows (32 global, 32 flat) match a byte-level model:

• the address is base + offset, with the global offset sign-extended
• unaligned accesses read the bytes at that address
• sbyte/sshort sign-extend, ubyte/ushort zero-extend
• inactive lanes are not written

The expected values in the test are the hardware outputs.

The HW ran under amdgpu's default unaligned access mode. The test therefore pins unaligned reads as byte-exact, which is what EmitBdaDwordReads already does through its byte path.

Tested

Arch Linux: RADV (Radeon 660M), lavapipe with local Mesa, and lavapipe with CI's version (Ubuntu Mesa 25.2.8). New test agc_driver_flat_global_loads_tests passes on all three.

Negative checks: the test fails if

• the flat offset loses bit 10
• the global offset is not sign-extended
• sbyte/sshort are zero-extended
• dwordx3 drops its last dword
• a 64-bit VGPR global address is treated as an SGPR-base offset

Mapping an unaligned span through the aligned dword path is not caught, because RADV and lavapipe both handle a misaligned dword OpLoad.

The test runs wave32 only. Each lane's load depends only on its own address, so wave64 adds no case. On CI's lavapipe the two dispatches take ~70 s with a cold shader cache, which is how CI runs: almost all of it is LLVM compiling the BDA lookups. With a warm cache it takes a few seconds, and under a second on RADV. Wave64 would double the time.

Full Release build (GCC) plus ctest: 183/184. The one failure, agc_driver_pixel_helper_lanes, also fails on main on local RADV since #305.

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

[oneandonlydean]

Thanks. I checked all 64 rows against a byte-level model of the two kernels (llvm-mc gfx1013 disassembly) and every value matches. The model uses base + offset with the global offset sign-extended, byte-exact unaligned reads, sign extension for sbyte/sshort, and the sentinels kept on EXEC-off lanes. Both the SADDR and the 64-bit VADDR global forms are covered, and the flat offsets go up to 2047.

One note: the test runs with the shader cache off, so on CI's lavapipe it pays the roughly 70 s compile every time. That's fine under the default timeout, so I'm not asking for a change.

Test only, no change to the translation. Ready to merge from my side.