[apollo-mg]

Overview

Extends the existing sm_61 exemption idiom to sm_60 across all three FAST_FP16 gates in
ggml/src/ggml-cuda/common.cuh: the device macro, fast_fp16_available(), and
fast_fp16_hardware_available() (the cuBLAS compute-type selector). 3 lines, sm_60 only.

Why: GP100's fp16 "fast path" (vec2 arithmetic in the FA tile kernel, mmvf, and
cuBLAS F16 compute type) costs measurable quality on P100 while buying zero real-world
throughput. Measured on Qwen3.6-27B Q6_K, wikitext-2, 2048 ctx, 32 chunks, vs an
fp32-arithmetic truth base:

config	median KLD	same-top
unpatched (fp16 arithmetic)	0.002298	96.53%
patched (fp32 arithmetic)	0.000001	99.89%

Performance impact negligible: pp8192@d8192 within noise on three model classes (hybrid 27B
318.5→318.6 t/s; dense 4B 357.9→358.0; hybrid-MoE 36B 304.4→304.1); tg +1.4% patched
on the hybrid. Real workloads are dominated by the int8 DP4A mmq path, which this
doesn't touch.

Validated against the same truth base: FA-on quantized-KV cells differ from stock in the fifth decimal due to this fork's modified FA stack. Anchor: this build's f16-KV run vs the stock-patched f32 truth base scores median 0.000001 / same-top 99.86% — the two trees are interchangeable post-patch.

Additional information

Scope: sm_60 only. sm_61 was already exempt (this mirrors it). sm_62 (Jetson TX2)
shares the gate and silicon but is unmeasured, so it's left untouched. Ampere+ FA
dispatches to the MMA kernels, which aren't gated by this macro — no behavior change
expected there (the 3090 mirror panel will confirm).

Worth investigating if other architectures experience any degradation in quality due to this gate.

Requirements

Nothing new. Just the patch.

• I have read and agree with the contributing guidelines
• AI usage disclosure: <Yes. Claude Fable 5. Bug discovery, root cause analysis, test methodology, benchmarking, writeup assistance. I monitored, supervised and guided the entire process.>

[TheTom]

Merged, thanks @apollo-mg. The truth-base methodology made this an easy call: the KLD delta (0.002298 to 0.000001) with perf inside noise is exactly the evidence needed for a quality-vs-speed carve-out, and scoping it to measured silicon only (leaving sm_62 alone) is the right discipline.

Verified on my side before merging: the three gates are the only 600-vs-610 distinction anywhere in the CUDA tree, so the carved sm_60 path is preprocessor-identical to the long-proven sm_61 path, and a Blackwell build showed bit-identical PPL with decode unchanged, confirming zero effect on other arches.

One cosmetic nit I noticed after merging: the #endif comment on line 263 still reads only != 610. If you happen to touch that file again feel free to sweep it, otherwise I will catch it in a cleanup pass.

Two solid, well-receipted contributions in a week between this and #206. Much appreciated.