[Nathan Chandrasekar (vera-rubin)]

On SSE, storing XMVectorReplicate(0.75f) with XMStoreByte4 or XMStoreUByte4 produces 0x00000001 instead of 0x01010101. XMStoreByteN4 similarly packs 0.25f as 0x1f1f1f1f instead of 0x20202020. The documented Byte4, UByte4, and ByteN4 operations round each component before packing.

We convert each clamped component to an integer before packing with SSE2 instructions, following the short-store implementation.

We checked the reproducer on SSE2, SSE4.1, and AVX2 and added a math3 regression that fails before and passes after, while the full suite retains its five existing math3 failures.

— ChipLab

[Chuck Walbourn (walbourn)]

I'll need to look closely at these proposed changes. There are a number of issues where I need to ensure that ARM matches, and that it doesn't negatively impact DirectXTex, etc. which is the primary consumer of these functions.

[Nathan Chandrasekar (vera-rubin)]

Yes: XMStoreUByteN4 and XMStoreByteN4 now use that pattern (_mm_packus_epi16 for the unsigned one), and XMStoreUByteN4 keeps its truncation, so its output is unchanged. On 27,993 four-lane test vectors, SSE, NEON and scalar now agree for UByteN4, UByte4 and Byte4, after adding the XMVectorRound the NEON XMStoreUByte4 and XMStoreByte4 paths lacked. XMStoreByteN4 still differs (scalar and NEON truncate, SSE rounds as documented): should SSE truncate too, or every path round?

[Chuck Walbourn (walbourn)]

Yes: XMStoreUByteN4 and XMStoreByteN4 now use that pattern (_mm_packus_epi16 for the unsigned one), and XMStoreUByteN4 keeps its truncation, so its output is unchanged. On 27,993 four-lane test vectors, SSE, NEON and scalar now agree for UByteN4, UByte4 and Byte4, after adding the XMVectorRound the NEON XMStoreUByte4 and XMStoreByte4 paths lacked. XMStoreByteN4 still differs (scalar and NEON truncate, SSE rounds as documented): should SSE truncate too, or every path round?

We should match the behavior of 'scalar', so truncate is probably the right choice.

[Chuck Walbourn (walbourn)]

The DirectXTex and DirectXMesh test suite are quite sensitive to changes in these 'packed' functions, so I think we need to also update DIRECTX_MATH_VERSION to 322 as part of this PR so I can handle the difference in the test suite.

[Nathan Chandrasekar (vera-rubin)]

Done: the SSE XMStoreByteN4 now truncates (_mm_cvttps_epi32) like the scalar and NEON paths, and DIRECTX_MATH_VERSION is 322. On the same 27,993 test vectors, SSE, NEON and scalar now agree for all four byte stores except NaN in the signed ones (-127 on SSE, 0 elsewhere, as before), and XMStoreUByteN4, XMStoreUByte4 and XMStoreByte4 produce exactly the same output as before.