[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

AF2i64 handled only the unsigned truncation of an F32 to 64 bits, which the 32-bit division sequence uses, and did it with float arithmetic. So F2I.S64.TRUNC (opcode 0x311, from cvt.rzi.s64.f32) failed to translate. A float approach also can't give the GPU's NaN and infinity results, because Metal's fast math assumes they don't occur.

The new path uses integer operations on the float's bits only:

• It decodes the sign, exponent and significand, with .FTZ flushing denormals and abs/negate applied to the sign.
• It shifts the significand into the two-word result, rounding by .TRUNC, .FLOOR, .CEIL or .ROUND from the dropped bits.
• It saturates out of range: signed gives 0x8000000000000000 / 0x7fffffffffffffff, and unsigned gives 0 below and all ones above.
• NaN gives 0x8000000000000000, or 0 with .NTZ.

The Orin confirms NaN, +inf and −inf give exactly those signed values. The unsigned truncation now takes the same path with the same results in range. It costs about 45 integer operations per F2I to 64 bits, a rare instruction.

Reference entry: "F2I to a 64-bit integer, signed or rounded" in docs/reference/shaders.md.

How to verify

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

The fixture's f2i_s64 program also loads a constant with HFMA2.MMA, which #2049 implements. So on this PR alone f2i_s64 stays in KNOWN, and the reason now names #2049. With #2049's one-line registration added, all 2,048 output words match the Orin. Whichever PR lands second should take f2i_s64 out of KNOWN.

Only the signed .TRUNC encoding is checked against the GPU. To cover the rest, I patched the program's F2I bits into 56 encodings (signed and unsigned, the four roundings, .FTZ, .NTZ, abs/negate) and ran each on this Mac's GPU over 5,120 inputs: every exponent, ties, and the fixture's rows. All 56 matched an exact model, and that model matches all of the Orin's rows.

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 4d9030e22125).
• 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