[l4nr3]

Problem

See #9. ir3_nir_lower_shuffle() turns shuffle(x, i) into rotate(x, i - gl_SubgroupInvocationID)
and, because that offset is divergent, into make_shuffle_uniform()'s loop with one iteration per distinct
offset. A shuffle where all invocations read the same source (or a few sources) therefore costs about one
iteration per invocation. With linux/0002 the index is (id & ~31) | (i & 31), which is never uniform, so
every such shuffle runs ~32 iterations.

Change

patches/linux/0006-ir3-shuffle-broadcast.patch, only in lower_shuffle() for nir_intrinsic_shuffle
with a 32-bit value:

• uniform absolute index: a broadcast — read_invocation_cond_ir3(x, id == i), no loop. This is the same
  sequence ir3 already uses for subgroupBroadcast (lower_read_invocation_to_cond).
• divergent absolute index: a new make_shuffle_mixed() loop. Each iteration reads both the absolute
  index and the relative offset of a not-yet-served invocation, then serves every invocation that wants the
  same absolute source (broadcast via read_invocation_cond_ir3) and every invocation that wants the same
  relative offset (rotate, as before). With half-wave subgroups a broadcast takes 2 iterations (one per
  half) instead of ~32. Every iteration finishes a whole group of invocations with the same offset, so it
  never needs more iterations than the current loop; for patterns that already were cheap (rotations, xor)
  the count is the same, but each iteration has a few more instructions.

Other bit sizes and shuffle_up/down/xor keep the existing lowering. Nothing is A8XX- or KGSL-specific;
the patch does not depend on linux/0002 and applies to plain Mesa main too.

Correctness notes

• Inactive invocations take no part in read_invocation_cond_ir3 / vote_all, as in the existing loop.
  If the source invocation is inactive or out of range the result is undefined (as the spec allows), and
  the loop still ends: the invocation that supplied the index is always marked done.
• Like make_shuffle_uniform(), the loop reads the next index with read_invocation_cond_ir3 under a
  condition that is true in several invocations, so it relies on the same behaviour of that macro. It does
  not need the absolute index and the offset to come from the same invocation.
• The broadcast read itself has exactly one invocation with a true condition.
• With half-wave subgroups gl_SubgroupInvocationID here is the hardware invocation id (0–63), and the
  index already contains the half base, so absolute indices stay inside the caller's half.
• A host-side model of both loops (random active masks; wave 32/64/128; uniform, half-wave, rotate, xor,
  random, few-sources and out-of-range indices) gives the expected value for every invocation whose source
  is active and in range, and never more iterations than the current loop.

Testing

• scripts/apply_patches.py linux on Mesa main 087e1fe4e6a5 (2026-10-27): the whole series including
  0006 applies. 0006 also applies on its own to plain Mesa main and to Mesa e2ab6687d5ad.
• Build check on the device (aarch64, Debian proot, gcc): Mesa main 087e1fe + the linux series + 0006
  builds libvulkan_freedreno.so with no warnings in ir3_lower_subgroups.c; plain Mesa main + 0006
  alone builds libfreedreno_ir3.a, also without warnings. Same meson options as build_linux.sh, except
  -Dplatforms=x11 (the Debian wayland-protocols is older than main now requires) and
  --wrap-mode=nodownload. This build was only compiled, not run; the run-time testing below is on the
  v0.3.4 base.
• RedMagic 11 Pro (Adreno 840, KGSL), DroidDeck 0.6.0, vkd3d-proton + FEX: built on DD-Turnip v0.3.4
  (Mesa e2ab6687d5ad + this series) with this change plus two local changes that are not part of this PR
  (the descriptor pool fix, and a pipeline cache key change I only used to force recompilation of shaders
  with GroupNonUniformShuffle). In 007 First Light the shader from the issue went from 94.6 to 8.4 ms per
  frame; menu 23 → 56 FPS, gameplay 6–7 → 12–15 FPS. The final NIR of that shader has 21
  read_invocation_cond_ir3 + 7 rotate + 7 vote_all instead of 7 + 7 + 7, the same 11 loops, and
  2 iterations per shuffle instead of ~32. I did not compare the image before and after.

Not tested: other games, other Adreno generations (A6XX/A7XX), MSM/DRM, the Android target, Vulkan CTS
(dEQP-VK.subgroups.shuffle.*), 16-bit shuffles (they keep the old path). Shaders that use
subgroupShuffle with a divergent index that is effectively a rotation or xor pattern get the same number
of iterations with a slightly longer body — not measured.

The patch is enabled for the linux target only, since that is what I tested; the uniform-index case
also exists without linux/0002, so the Android target could benefit as well.

Fixes #9