[oneandonlydean]

What

A wave64 compute or mesh program on a 32-wide host runs two lanes per invocation (laneCount == 2), and EmitStructuredBlock emits every IR value once per lane. That includes the values the whole wave shares: each SGPR value, scalar memory load and loop phi exists twice in the module, which raises register pressure for every such program.

Changes:

• WaveUniformValues (in SpirvAnalysis) finds the values every lane of the wave computes alike. It is a fixed point over the program:
  • Uniform sources: user data, the shader base, resources, ReadConst/ReadConstBuffer, Ballot, ReadLane and ReadFirstLane.
  • Lane sources: LaneId, builtins other than the workgroup id, attributes and interpolation parameters, DPP/permlane/bpermute/swizzle, WriteLane, append/consume, and every buffer, shared, address or image access.
  • A scalar load (an address read of a ScalarAddress resource) counts as uniform when its operands are, since the wave performs it once.
  • Anything else is lane-varying exactly when one of its operands is.
• For a value in that set that has a type and no side effects, the second lane reuses the first lane's definition instead of emitting the instruction again. Both lanes are one invocation, so they always take the same control flow, and the first lane's definition sits exactly where the second lane's would have been.

I checked that no emitter puts the first lane's definition inside a conditional of its own. The conditionals some emitters open (BDA reads, EmitValueOrZeroIfCondition, BDA fault returns, storage image mip switches) close at their merge block, and the result is an OpPhi there. The per-lane loop emits each instruction unconditionally for both lanes. A forward reference that the second lane allocated earlier through Result gets an OpCopyObject from Define, as before.

On my integration branch, four ray-traced lighting programs and one other wave64 compute program of PPSA21564 compile to about 12% fewer SPIR-V words with this change. On the RTX 4090, the two-lane modules of those programs had needed more than 255 registers and spilled to local memory.

Tested

• Linux (CachyOS, RTX 4090, NVIDIA 610.57.04, subgroup size 32).
• agc_shader_memory_tests:
  • verifyWaveUniformValues checks the analysis on a small program. User data, a sum of it, an address resource, a scalar load through a uniform address, a value computed from that load and a ballot are uniform. LaneId, a sum with it, a scalar load at a lane-dependent offset, a global load, a value computed from the global load and a per-lane compare are not.
  • verifyTwoLaneUniformValues recompiles a wave64 program (s_load_dwordx2, s_mul_i32, v_add_nc_u32, buffer_store_dword) for 32- and 64-wide hosts and requires the same number of OpIMul in both. Without the emitter change it fails (a two-lane invocation computes a scalar value once per lane); with the change it passes.
• New agc_driver_wave_uniform execution test (tests/execution/WaveUniform.cpp, so ctest runs it like the other tests there): a 64-thread wave64 program with an s_buffer_load_dwordx2, a scalar loop whose phis feed a multiply, s_bcnt1_i32_b64 of a VCC ballot and a v_readfirstlane_b32 checks every lane's stored result. It passes on the RTX 4090. As a check of the test itself, wrongly treating builtins as uniform makes it fail (thread 1 stored 1022, expected 1002). Like the other execution tests it exits 77 (skipped) without a Vulkan device, and it also skips on a subgroup narrower than 32 (lavapipe's is 8), where a wave64 does not fit in two lanes.
• agc_driver_bda_device_tests and agc_driver_mesh_tests pass. agc_driver_recompiler_tests fails with missing register at DWORD 0x207 on main as well.
• ctest: 106/106 pass, including the execution tests.
• PPSA21564: this change has been on my integration branch through repeated passes of my visual regression check (from the intro video through the title and save menu into gameplay; checkpoint frames, flicker, video tearing and FPS).

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