metal: add F16 input to the FWHT

[bri-prism]

Overview

The Metal FWHT kernel accepts F32 input only. This makes the source type a template
parameter, so the kernel reads an F16 source directly instead of requiring a converted
copy. The F32 instantiations are unchanged.

The pipeline name now carries the source type, and supports_op accepts an F16 src1
for the Hadamard hint at the four sizes the kernels cover. Every other F16 src1 path
still goes through ggml_metal_supports_mul_mat_op.

This is the backend follow-up to #27779, which added F16 input to the CPU FWHT and noted
that the test cases would come with the first backend kernel. Those cases are included here.

Additional information

ggml_metal_fwht_supported_size moves from ggml-metal-ops.cpp to ggml-metal-device.h
so supports_op in ggml-metal-device.m can use the same list. It does not go in
ggml-metal-impl.h, which the shaders include through common.h.

The F16 gate in supports_op is restricted to the sizes that have kernels. Outside those
sizes an F16 src1 keeps the existing behaviour, so the fallback never sees an F32 src0
against an F16 src1.

Tested on an M5 Pro with test-backend-ops:

• MUL_MAT_HADAMARD 16/16, including the seven new F16 cases
• MUL_MAT 1265/1265, no regressions

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES. Claude Code was used to write and test this change, following the
  structure of the CPU version in ggml-cpu: add F16 input to the FWHT #27779, and to format this description to the PR template.
  I reviewed every line and take full responsibility for the changes.

[ggerganov]

Not sure how performance critical this kernel is, but you might want to check the suggestions below.

[ggerganov]

Have you tried explicitly unrolling some of these loops using FOR_UNROLL? My experience is that it can help in many cases.

[ggerganov]

Have you tried if this improves perf:

Suggested change

	reg[j] = val2 - val + 2*((lane & i) == 0)*val;

[bri-prism]

Pushed a fix on top, so this needs another look.

The supports_op branch I added admitted an F16 src1 based on the type, the hint and the width, but the dispatch also requires src1 and dst to be contiguous and the same shape. An op that passed the first check and failed the second fell through to the generic path, which has no F32 src0 by F16 src1 kernel, and aborted on a nil pipeline. A Hadamard-hinted matmul with an F16 src1 and m != k reproduces it.

The condition now lives in one place, ggml_metal_use_fwht, and both supports_op and the dispatch call it, so they cannot disagree again. I added the case that aborted as a test.

[khosravipasha]

@ggerganov Thanks trying the suggestions now to see if it helps.
Also the Q2_0 is uploaded here if you want to test/play around with it yourself:

(it would need this PR and 1-2 of other draft PR's @bri-prism has sent).

https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf-dev

[ggerganov]

These should not be implemented here. See the ggml_metal_op_mul_mat_use_mm pattern.

[ggerganov]

I can't push to your branch - please apply this patch:

diff --git a/ggml/src/ggml-metal/ggml-metal-common.cpp b/ggml/src/ggml-metal/ggml-metal-common.cpp
index 58a0bb038e..5ce5352da2 100644
--- a/ggml/src/ggml-metal/ggml-metal-common.cpp
+++ b/ggml/src/ggml-metal/ggml-metal-common.cpp
@@ -7,17 +7,8 @@
 
 #include <vector>
 
-bool ggml_metal_op_mul_mat_use_mm(const struct ggml_tensor * op, bool has_simdgroup_mm) {
-    const int64_t ne00 = op->src[0]->ne[0];
-    const int64_t ne11 = op->src[1]->ne[1];
-
-    return !ggml_is_transposed(op->src[0]) &&
-           !ggml_is_transposed(op->src[1]) &&
-           has_simdgroup_mm && ne00 >= 64 && ne11 > 8;
-}
-
 // must stay in sync with the kernel_fwht_<type>_<N> templates in misc.metal
-bool ggml_metal_fwht_supported_size(int64_t n) {
+static bool ggml_metal_fwht_supported_size(int64_t n) {
     return n == 64 || n == 128 || n == 256 || n == 512;
 }
 
@@ -34,6 +25,15 @@ bool ggml_metal_op_mul_mat_use_fwht(const struct ggml_tensor * op) {
            ggml_metal_fwht_supported_size(op->src[1]->ne[0]);
 }
 
+bool ggml_metal_op_mul_mat_use_mm(const struct ggml_tensor * op, bool has_simdgroup_mm) {
+    const int64_t ne00 = op->src[0]->ne[0];
+    const int64_t ne11 = op->src[1]->ne[1];
+
+    return !ggml_is_transposed(op->src[0]) &&
+           !ggml_is_transposed(op->src[1]) &&
+           has_simdgroup_mm && ne00 >= 64 && ne11 > 8;
+}
+
 bool ggml_metal_op_mul_mat_id_use_mm(const struct ggml_tensor * op, bool has_simdgroup_mm) {
     const int64_t ne00 = op->src[0]->ne[0];
     const int64_t ne21 = op->src[2]->ne[1];
diff --git a/ggml/src/ggml-metal/ggml-metal-common.h b/ggml/src/ggml-metal/ggml-metal-common.h
index a9986bf245..e6a28d032d 100644
--- a/ggml/src/ggml-metal/ggml-metal-common.h
+++ b/ggml/src/ggml-metal/ggml-metal-common.h
@@ -3,7 +3,6 @@
 #pragma once
 
 #include <stdbool.h>
-#include <stdint.h>
 
 #ifdef __cplusplus
 extern "C" {
@@ -49,13 +48,10 @@ bool ggml_mem_ranges_check(ggml_mem_ranges_t mrs, const struct ggml_tensor * ten
 void ggml_graph_optimize(struct ggml_cgraph * gf);
 
 // mat-mat vs mat-vec dispatch; used by both supports_op and ggml_metal_op_mul_mat*
+bool ggml_metal_op_mul_mat_use_fwht (const struct ggml_tensor * op);
 bool ggml_metal_op_mul_mat_use_mm   (const struct ggml_tensor * op, bool has_simdgroup_mm);
 bool ggml_metal_op_mul_mat_id_use_mm(const struct ggml_tensor * op, bool has_simdgroup_mm);
 
-// FWHT dispatch; used by both supports_op and ggml_metal_op_mul_mat
-bool ggml_metal_fwht_supported_size    (int64_t n);
-bool ggml_metal_op_mul_mat_use_fwht    (const struct ggml_tensor * op);
-
 #ifdef __cplusplus
 }
 #endif

[bri-prism]

Pushed fixes for all three review comments. The branchless butterfly select and the dispatch predicate move are both applied as suggested (measured +3.0% on M5 Pro for the butterfly change). I also tried FOR_UNROLL on the same loops but it made no consistent difference across rounds, so I left that one out. Ready for another look whenever you have time.