cuda/hip: optional wave64 for the quantized mat-vec kernels on RDNA

[mgehre-amd]

Adds GGML_HIP_MMVQ_WAVE64, off by default, which builds mmvq.cu with
-mwavefrontsize64.

@Annieren,
This is exploratory rather than a proposed default. RDNA can pick a wave size per kernel, and for
a couple of shapes wave64 is a clear win - but for more of them it is a clear loss. The point of
the PR is to expose the switch and record the measurements so the tradeoff is visible, rather
than have the next person rediscover it.

21 lines of change.

Which shapes benefit, and which don't

q4_K, rocprofv3 kernel time, median of 3 interleaved passes, gfx1151 / Radeon 8060S,
ROCm 7.15.0a20260728, GGML_CUDA_DQ_MMV=0:

shape	wave32	wave64	delta
m=21504 n=1 k=5376 (gemma-4 fused FFN gate/up)	289.6 us	285.6 us	-1.4%	win
m=4096 n=4 k=14336	117.6 us	110.0 us	-6.5%	win
m=4096 n=8 k=14336	210.0 us	223.1 us	+6.2%	loss
m=4096 n=4 k=4096	35.1 us	40.5 us	+15.4%	loss
m=4096 n=1 k=4096	32.3 us	37.5 us	+16.2%	loss
m=4096 n=1 k=14336	54.1 us	69.6 us	+28.7%	loss

Two of six shapes benefit. The one that motivated the work - the gemma-4 fused FFN gate/up matvec

• gains 1.4%. Before landing, we would need to investigate the other changes or guard the change to only the benefiting shapes.

The likely mechanism is the K-loop trip count. blocks_per_iter = vdr * nwarps * warp_size / qi,
so doubling the wave size halves the iteration count. At k=4096 with nwarps=2 that is two
iterations instead of four, and the 4x unroll from the parent PR has nothing left to pipeline.
The shapes that win are the ones with enough K to keep it fed.

Which types benefit, and which don't

All 21 mmvq types at m=4096 n=1 k=4096, median of 3 passes. Note this is the shape where q4_K
itself does worst, so read it as one slice, not a verdict:

improves >2%		regresses >2%
iq2_xs	-12.8%	q4_K	+18.7%
iq2_xxs	-12.5%	iq4_xs	+15.5%
iq3_xxs	-12.5%	mxfp4	+9.8%
iq2_s	-11.2%	nvfp4	+9.1%
iq3_s	-5.7%	q2_K	+7.7%
		q4_0	+5.4%
		iq1_s	+4.7%
		iq4_nl	+4.4%
		q5_0	+2.4%

Seven more (q6_K, q4_1, q5_K, q3_K, q8_0, q1_0, q5_1) are within +/-2%. The iq2/iq3 family is the
consistent winner; everything with a cheap vec_dot tends to lose.

Why it is a build flag and not something narrower

-mwavefrontsize64 is a per-translation-unit flag, so it flips all 265 kernels in mmvq.cu,
not just the q4_K one. It is not applied target-wide because fattn-mma-f16.cuh static_asserts on
wave32 tiling.

A function attribute cannot narrow it. __attribute__((target("wavefrontsize64"))) does work in
isolation - it emits .wavefront_size: 64 for that kernel alone - but clang then refuses to
inline any wave32 function into it:

error: always_inline function 'warp_reduce_sum' requires target feature 'wavefrontsize32',
       but would be inlined into function 'k64' that is compiled without support for
       'wavefrontsize32'

That extends to threadIdx accessors, and every kernel here is assembled from __forceinline__
helpers, so there is nothing left to attribute. Narrowing this properly means moving the q4_K
instantiation into its own translation unit compiled with the flag, which is a larger change and
is not attempted here.

Verification

test-backend-ops test -o MUL_MAT,MUL_MAT_ID,MUL_MAT_VEC_FUSION,MUL_MAT_ID_FUSION -b ROCm0
passes with the flag on, with and without GGML_CUDA_DQ_MMV=0.

Reproducing

cmake -B build64 -DGGML_HIP=ON -DAMDGPU_TARGETS=gfx1151 -DCMAKE_BUILD_TYPE=Release \
      -DGGML_HIP_MMVQ_WAVE64=ON
cmake --build build64 --target test-backend-ops -j$(nproc)

GGML_CUDA_DQ_MMV=0 ./build64/bin/test-backend-ops perf -o MUL_MAT -b ROCm0 \
    -p 'type_a=q4_K,type_b=f32,m=4096,n=1,k=14336'

Runs were serialised under exclusive GPU access at DPM level high and gated on the GPU edge
sensor at 52 C.