[bri-prism]

Overview

#29100 broke the MUSA Docker build. The wide FWHT kernel fwht_cuda_block<N, 256, T> keeps a full row in a static __shared__ float s[N] array, so at N=8192 it needs 33300 bytes of shared memory per block. MUSA mp_21 allows at most 28672, so both the F32 and F16 instantiations fail to compile:

error: shared memory (33300) exceeds limit (28672) in function '_Z15fwht_cuda_blockILi8192ELi256EfEvPKT1_Pflf'
error: shared memory (33300) exceeds limit (28672) in function '_Z15fwht_cuda_blockILi8192ELi256E6__halfEvPKT1_Pflf'

CUDA allows 48 KB of static shared memory by default, so CUDA builds were not affected, and the PR CI does not build MUSA.

This PR compiles the 8192 case out on MUSA. On MUSA, an 8192-wide FWHT returns false from ggml_cuda_op_fwht_impl and takes the existing generic fallback, the same path widths without a kernel already use (covered by the 16384 case in #29100). Widths 1024 to 4096 keep the wide kernel on MUSA; 4096 needs about 16.9 KB. CUDA and HIP are unchanged.

Additional information

Failing job: https://github.com/ggml-org/llama.cpp/actions/runs/37727833228/job/113151497895

I don't have a MUSA toolchain, so this was not compiled for MUSA locally. I checked that preprocessing removes the 8192 case only when GGML_USE_MUSA is defined. @yeahdongcn, could you confirm the build on your side?

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES. Claude Code traced the failure from the CI log and wrote the change. I reviewed it and take full responsibility for the changes.

[JohannesGaessler]

@yeahdongcn my stance is that I am fine with keeping the MUSA stuff in the ggml CUDA backend but only insofar it does not cause a significant maintenance burden. Having to cater to a reduced max. shared memory size is explicitly not something that I want to do.

[CISC]

CUDA allows 48 KB of static shared memory by default, so CUDA builds were not affected, and the PR CI does not build MUSA.

It does build MUSA, but only arch 31 to save time, we might consider changing that to 21 to catch these issues.

To that effect this change can probably be gated to arch <= 21 only as it's likely to work on other, but @yeahdongcn can follow up on that.

[yeahdongcn]

@yeahdongcn my stance is that I am fine with keeping the MUSA stuff in the ggml CUDA backend but only insofar it does not cause a significant maintenance burden. Having to cater to a reduced max. shared memory size is explicitly not something that I want to do.

This is indeed a hardware limitation. As mentioned in #30080, all MUSA architectures except mp21 (MTT S80) support more than 48 KB of static shared memory, making them compatible with NVIDIA in this regard.

I'm thinking of updating the Docker build to drop mp21 support. Would that be a better approach? It seems like a cleaner, one-time solution that would avoid adding maintenance overhead to the CUDA backend. What do you think? @JohannesGaessler @CISC

Please see: #30203