[Know-It-All-Brother]

Part of the Ampere accuracy series (#2040). It depends on #2041 for the test: the commits before this PR's own are #2041's and drop out once it lands, so this PR's own change is the last commit.

What and why

HFMA2.MMA is HFMA2 issued on the tensor pipe. ptxas emits it for ordinary fma.rn.f16x2, and even more often as a way to load a 32-bit constant: HFMA2.MMA Rd, -RZ, RZ, 0, imm. The translator refused it (opcodes 0x235 and 0x435), so any shader with one failed to translate. None of Ocarina of Time's translated shaders has one, but the compiler emits it for plain PTX, so other games' shaders can.

Its fields are HFMA2's; only opcode bit 2 differs (0x035 against 0x031 in the low 9 bits). That holds in the Orin's encodings (.SAT at bit 77, .RELU at 79, .FTZ at 80) and in Mesa NAK's HFMA2 layout. The fix registers 0x035 with HFMA2's emitter, which also covers the constant-bank and uniform forms. The MSL is identical to HFMA2's, so #1902's single-rounding rewrite applies to it as well, and the constant idiom comes out as a constant.

Making these ops run exposed one more bug, which this PR fixes since it's the same emitter. .RELU on HFMA2, HFMA2.MMA and HMUL2 turned a NaN result into 0, but the GPU keeps the NaN (PTX's .relu gives the canonical NaN). It's now isnan(v) ? v : max(v, 0) on .RELU forms only.

Reference entry: "HFMA2.MMA, the half-pair FMA on the tensor pipe" in docs/reference/shaders.md.

How to verify

DMSH_TEST_XLATE=dm/gfx/tools/dmsh_xlate_bin/dmsh_xlate python3 dm/gfx/tests/test_dmsh_ampere_orin.py

On main, 17 fixture ops failed to translate because of HFMA2.MMA. With this PR:

Ops	Result
hfma2, hfma2_sat, hfma2_relu	match (only NaN bit patterns, Metal's own); hfma2_relu had 314 NaN-to-0 lanes before the .RELU fix
f2f_tf32, iadd64, isub64, imul64, imul24, idiv_u32, irem_s32, idiv_u32_by_7	match exactly, so the integer division, 64-bit and 24-bit sequences the compiler builds now translate correctly
mufu_rcp	runs; within 1 ULP of the Orin like mufu_rcp_ftz, so it joins the approximations list
hfma2_ftz	runs; still differs until #2048's .FTZ fix. With both PRs together it matches (332 of 2,048 halves, all NaN bit patterns), so whichever lands second should take hfma2_ftz out of KNOWN
fdiv_rn, f2i_s64, dadd, dmul	now stop at the next missing instruction (FCHK, F2I.S64, DADD, DMUL), listed in KNOWN with those reasons

None of the HFMA2 cases shows #1902's double rounding: it's rare (70 in 2 million lanes on the Orin), and the fixture's 1,024 cases don't include one.

Not checked against the Orin: the constant-bank and uniform-register forms, which aren't in the fixture. With .RELU, the select sits between the fma and the pack, so #1902's rewrite may not match those forms.

Checked

• Tests: test_dmsh_ampere_orin.py, test_dmsh_hmma.py; every other test_dmsh_* gives the same result as on main (test_dmsh_ampere_mem.py, test_dmsh_meshstage.py and test_dmsh_pairs.py fail on main the same way); test_nsp_chain.py, test_xlate_anycpu.py, test_docs.py. lint_python.py shows no new findings.
• Translator: the dlls are rebuilt from this tree with .NET 10; tool_lock.py --update-lock and dmsh_chain.py --header were run (chain ffb778cb19be).
• Devices and OS: MacBook Pro M5 Max, macOS 27.
• regress.py: not run. My only local Switch 2 build's shader package comes from an older shader split than main's map, so main's chain can't build it. I'll add a report once I have a fresh build.
• Games run: none.

Docs

• docs/reference/shaders.md has the entry, and python3 dm/tools/docs_symptoms.py was run
• A chain tool changed: dmsh_chain.py --header was run, and dmsh_chain.h, the translator dlls and the lock are part of the change
• No game files, keys or data extracted from a game