[bong-water-water-bong]

Refs 1bit-MONSTER/engine#2167. Tests only. Supersedes the test rows of #307.

What ggml-org#2167 reported, and what ran

MUL_MAT_ID(type_a=bf16, ..., m=512, n=32, k=256) with activations to 1e5 returned NaN against a finite CPU result, "at pin 7a1f2b81c". That case runs on ggml_mul_mat_id_f32_f32_wmma, whose tile path has narrowed the activation at 2^-6 since dfbf2b1a3 (#285), which is in that pin.

The report's build was ~/wt/i1467-build, made from ~/wt/i1467-src at 33f72d6d1 (#307's branch). git merge-base --is-ancestor says dfbf2b1a3, 2293f95ea and 7a1f2b81c are not in that tree, and its copy of the kernel has no 0.015625. So the NaN was measured on the backend from before #285, not on the pin.

Measured on the pin and on the tip (gfx1151, one gpu-hold ticket)

One test binary with these rows, run against the public backend library built from the engine pin 204493d40 and from fork 2b7960bae:

pin (lib 6865bbfdef19)                                                          tip (lib e0ed1cdcdd7d)
  MUL_MAT_ID(type_a=bf16,...,m=512,n=32,k=256,activation_scale=10000):  OK        OK
  MUL_MAT_ID(type_a=f32, ...,m=512,n=32,k=256,activation_scale=10000):  OK        OK
  MUL_MAT_ID(type_a=q4_K,...,m=512,n=32,k=256,activation_scale=10000):  OK        OK
  MUL_MAT_ID(type_a=bf16,...,m=512,n=32,k=256,activation_scale=100000): OK        OK
  MUL_MAT_ID(type_a=f32, ...,m=512,n=32,k=256,activation_scale=100000): OK        OK
  MUL_MAT_ID(type_a=q4_K,...,m=512,n=32,k=256,activation_scale=100000): OK        OK
  MUL_MAT_ID(type_a=bf16,...,m=512,n=1, k=256,activation_scale=100000): OK        OK

The "before" is the report's own run on the pre-#285 backend: the bf16 row at 1e5, HRX0=-nan CPU=-165957.6875.

The change

tests/test-backend-ops.cpp: test_mul_mat_id takes an activation scale (default 1, so every earlier case is the same test), and seven rows use it. Two differences from #307's version of the parameter:

• only the activation b is scaled. tests: pin the MUL_MAT_ID activation range the f16 narrowing handles (Refs engine#2127) #307 scaled every f32 tensor, so with f32 weights it also put the weights at 1e5; that row fails on any backend that multiplies in half precision and says nothing about activations (I hit it: HRX0=-nan CPU=59434102784).
• the 1e5 rows are in, because they pass.

#307 can be closed: its remaining content is the 1e4 row, which is here, and its branch still carries the gated-delta-net guard change of #301 and the scheduler hunks.

Not run: the whole MUL_MAT_ID op with these rows at the current tip caa2d4dde (the rows were run at 2b7960bae; at that commit the op was 850 OK with the earlier form of these rows).

🤖 Generated with Claude Code

[bong-water-water-bong]

ready for review at 8dd46e9 (tests only; rows measured on the pin's and the tip's backend, output in the body)

[bong-water-water-bong]

VERDICT at 8dd46e9: READY

The helper is the point: init_mul_mat_id_tensors(ctx, n_mats, float activation_scale = 1.0f) lets a test build activations above the half-precision range deliberately, scaling only the b tensor. Without it the overflow case that the 2⁻⁶ prescale exists for cannot be reached from a test at all — every fixture would sit comfortably inside f16 and pass whether or not the narrowing was correct.

That is what was missing from the family: #285/#284/#307/#309 all narrow before the truncation, and the argument that doing so is necessary rests on a case that no test could produce. A parameterised fixture makes the boundary reachable, which is the difference between a test that pins the fix and a test that merely runs beside it.