[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

Three half-pair forms failed to translate: HMNMX2 .NAN (min.NaN.f16x2), and the bfloat16 forms HMNMX2 .BF16_V2 (min / max.NaN on bf16x2) and HFMA2 .BF16_V2 (fma.rn.bf16x2). The half-pair helpers only knew f16 lanes. The fields from the Orin's encodings are .NAN at bit 81 and .BF16_V2 at bit 85.

• bf16 lanes unpack as bits << 16 (low) and bits & 0xffff0000 (high), and pack by rounding to nearest even with integer operations. A NaN packs to 0x7fff, as the Orin writes it whatever its sign.
• HMNMX2 on bf16 compares integer keys that order like the floats with −0 below +0, as the Orin does. Without .NAN, one NaN gives the other operand and two give NaN; with .NAN, any NaN gives NaN.
• HMNMX2 .NAN on f16 keeps the existing min / max and overrides a lane with NaN where an operand is NaN. It doesn't collide with FMNMX and HMNMX2 order -0 below +0, as the GPU does (chain change) #2047's ±0 change.
• Still refused: HADD2 / HMUL2 .BF16_V2, which PTX only offers on sm_90 so the fixture can't check them, and HMNMX2 .F32 / .XORSIGN.

These forms aren't hot. A bf16 FMA costs about 8 integer operations per lane for the rounding, and a bf16 min/max about 12.

A change to the test, which I want to be upfront about: compare.py now treats a bf16 denormal like an f32 one. Metal computes bf16 in f32, so it flushes bf16 denormals just as it flushes f32 ones. All 31 lanes bfma2 still differs in are of that kind (for example inf × the bf16 denormal 0x0001 is inf on the Orin and NaN on Metal). The change only reclassifies bfma2 and f2fp_pack_bf16x2, which is still listed. If you'd rather not widen the rule, bfma2 can go back into KNOWN with the reason "bf16 denormals flushed by Metal".

Reference entry: "bf16 half pairs and HMNMX2.NAN" in docs/reference/shaders.md.

How to verify

DMSH_TEST_XLATE=dm/gfx/tools/dmsh_xlate_bin/dmsh_xlate AMPERE_ORIN_ONLY=hmin2_nan,bmin2,bmax2_nan,bfma2 python3 dm/gfx/tests/test_dmsh_ampere_orin.py

Op (halves of 2,048)	main	this PR
hmin2_nan	failed to translate	0
bmin2	failed to translate	0
bmax2_nan	failed to translate	0
bfma2	failed to translate	31, all bf16 denormals (30 inputs, 1 result)

All four come out of KNOWN. The bf16 FMA computes in f32 and then rounds to bf16, which is two roundings. A model of that matches all 1,533 finite fixture lanes, but a case where the f32 result lands exactly on a bf16 tie that the exact result wasn't on would round wrong, and the fixture has none.

Checked

• Tests: test_dmsh_ampere_orin.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 7b4846c830cd).
• 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. Ocarina of Time's build already translates every shader, so it can't contain this instruction.
• 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