[fxd0h]

What and why

The translator writes HFMA2 as fma(a, b, c) on the halves unpacked to float, then packs with half2(float2(..)): two roundings. The hardware rounds a * b + c once. Measured on a Jetson Orin (sm_87, PTX fma.rn.f16x2) on Nov 7, 70 of 2,097,152 lanes were one half ULP off (99.9967% identical). For example, -3136 × -8.125 + 0.000124693 gives 25488 on the Orin and 25472 on Metal.

hfma_msl rewrites a half-only fma that is packed back to half into dmsh_hfma. That helper rounds the float result to odd from a TwoSum, so the conversion to half rounds once. It's compiled in safe math with contraction off, because fast math folds the TwoSum. FFMA → F2FP and HFMA2.F32 are left alone, since the hardware rounds twice there as well. Reference entry: HFMA2 rounds twice to half.

Checked

• test_dmsh_hfma.py (8 tests). Its fixture holds 1,500 of the Orin's edge triples plus the 70 lanes. After the change, 0 of 2,097,152 lanes differ, in default, fast, safe and relaxed math. test_dmsh_hmma.py, test_nsp_chain.py and test_docs.py also pass.
• M5 Max, macOS 27.2. No game run: the 70 lanes are rare inputs, and no picture change is expected.
• It's a chain change, so every game's shaders that use HFMA2 rebuild.

[Know-It-All-Brother]

I ran this branch through the Orin value test from #2041, together with #2049. ptxas compiles fma.rn.f16x2 to HFMA2.MMA, and without #2049 the fixture's HFMA2 ops don't translate at all. The test now picks up hfma_msl from finish(), so it runs your rewrite as a build would.

No regressions. Of the 193 ops, the only one that changes against main plus #2049 is hmma_16816_f16, and that's because this branch is based before #1897 (HMMA's once-per-8 rounding). It goes away on a rebase.

Your rewrite covers HFMA2.MMA too. Its MSL has the same shape as HFMA2's, and hfma_msl turns both lanes of the plain and .SAT forms into dmsh_hfma.

It doesn't fire on .RELU. The Orin keeps a NaN result under .RELU (PTX's .relu gives the canonical NaN), so #2049 changes .RELU from a plain max(v, 0) to keep the NaN. The MSL between the fma and the pack is now:

float _63 = fma(_51, _55, _59);
bool _69 = isnan(_63);
float _71 = fast::max(_63, 0.0);
float _73 = _69 ? _63 : _71;
...
uint _81 = as_type<uint>(half2(float2(_73, _79)));

Could hfma_msl also match this select form, applying the clamp to dmsh_hfma's result? If you'd rather keep the pattern simple, I can move .RELU in #2049 so it's applied after the pack instead. Just tell me which you prefer.

What this can't confirm. The fixture has 1,024 cases per op and none of the rare double-rounding inputs, so it doesn't prove the single rounding itself. Your 4,570-case fixture does that. What it does show is that nothing else moves.

Running it also turned up a bug in my test: it didn't give the rewrites dmsh_build.py's imports, and hfma_msl uses struct. That's fixed in #2041.

To rerun once #2041 is in: DMSH_TEST_XLATE=dm/gfx/tools/dmsh_xlate_bin/dmsh_xlate python3 dm/gfx/tests/test_dmsh_ampere_orin.py, with AMPERE_ORIN_ONLY=f16x2 for the half ops.

[Know-It-All-Brother]

A heads-up about an interaction with #1774 (the shader loop guard), which I hit when I put this PR and #1774 on one branch together. Neither breaks on its own, but whichever lands second will.

loop_guard inserts uint dm_lg = 0u; (void)dm_lg; at the start of every function body, including dmsh_hfma. Metal only accepts #pragma METAL fp at file scope or at the start of a compound statement, so the helper's two pragmas stop compiling, and every shader with an HFMA2 fails to build:

error: '#pragma METAL fp' can only appear at file scope or at the start of a compound statement
#pragma METAL fp math_mode(safe)

Your test doesn't see it because its kernels don't go through loop_guard. The Orin suite in #2041 does, since it applies every rewrite in finish().

The fix I used, at the end of loop_guard, keeps a function's leading pragmas ahead of the guard:

return re.sub(r'(\n    uint dm_lg = 0u;[^\n]*)((?:\n#pragma [^\n]*)+)', r'\2\1', '\n'.join(out))

With that, this PR and #1774 build together, and test_dmsh_hfma.py, test_dmsh_loop_guard.py and the Orin suite all pass. Alternatively, loop_guard could skip functions that have no loop, since dmsh_hfma has none. Either way, it's probably worth a test case on whichever PR lands second.

[fxd0h]

thanks for running it through the orin suite. rebased on main, and hfma_msl now also takes the isnan(v) ? v : max(v, 0) form, so you can keep .RELU as it is in #2049. moved the pragmas into a block of their own inside the helper, so a line loop_guard puts at the top of the body can't break them, whichever lands first. added tests for both