[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.

[Chuck Walbourn (walbourn)]

Can we use the same _mm_packs_epi32 / _mm_packs_epi16 pattern with XMStoreUByteN4 and XMStoreByteN4?

[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?