Which versions of Windows support/require which CPU multimedia extensions? (How to check if SSE or AVX are fully usable?)

Solution 1:

Extensions that introduce new architectural state require special OS support, because the OS has to save/restore restore more data on context switches. So from the OSes perspective, there's nothing extra it needs to do to let user-space code run SSSE3 instructions, if the OS supports SSE.

SSE, AVX, and AVX512 are the extensions that introduced new architectural state.

• SSE introduced the xmm regs (and MXCSR for rounding modes and FP exception state)
• AVX introduced ymm (the lower half of which are the old xmm regs).
• AVX512 introduced zmm (extending the x/ymm regs), and also doubled the number of vector regs in 64bit mode: zmm0-zmm31. x/y/zmm16..31 are only accessible with AVX-512 encodings of vector instructions (EVEX prefix), and thus interestingly can be used without requiring vzeroupper, and aren't affected by it.
  k0..k7 64-bit mask registers (or 16-bit without AVX-512BW in Xeon Phi) are also new in AVX-512.

You check for CPU support for SSE or AVX the usual way, with the CPUID instruction.

To prevent silent data corruption when using a new extension on a multi-tasking OS that doesn't save/restore the new architectural state on context switches, SSE instructions fault as illegal instructions if the OS hasn't set an OS-support bit in a control register. So vector extensions "don't work" on OSes that don't know about saving/restoring the necessary state for that extension.

For SSE, there may not be any clean OS-independent way to detect that the OS has promised to save/restore SSE state on context switches by setting the CR4.OSFXSR, CR4.OSXMMEXCPT etc. bits, because even reading a control register is privileged, and there's no CPUID bit that reflects the setting. SSE support is so widespread that you'd have to be using a really ancient version (or homebrew) OS for this to be a problem.

For AVX, we don't need OS support to detect that AVX is usable (supported by hardware and enabled by the OS): User-space can run xgetbv and check the enabled-feature flags to see if the OS has enabled AVX instructions to run without faulting.

From Intel's intro to AVX:

• Verify that the operating system supports XGETBV using CPUID.1:ECX.OSXSAVE bit 27 = 1.
• At the same time, verify that CPUID.1:ECX bit 28=1 (Intel AVX supported) and/or bit 25=1 (AES supported) ... (and other bits for FMA, AES, and PCLMULQDQ)
• Issue XGETBV, and verify that the feature-enabled mask at bits 1 and 2 are 11b (XMM state and YMM state enabled by the operating system).

It may be easier to call an OS-provided function to detect OS support, instead of using inline asm or a feature-detect library to do all this. For example, Win7SP1 introduced GetEnabledXStateFeatures along with support for AVX CPUs. (It's unlikely or maybe impossible to find Win7SP1 running on a CPU without SSE, so for SSE you can just check CPUID and OS version.)

This is also understood to be a promise that the OS's context switches will correctly save/restore the full state, although of course a buggy, malicious, or esoteric OS (perhaps cooperative multi-tasking?) could be different. For mainstream OSes including Windows, it does mean YMM registers will keep their values just like you'd expect.

The same is true for AVX512: you can check the CPUID feature bit for the instruction set, and check that the OS has promised to manage the new architectural state on context switches by enabling the right bits in with XSETBV. (So you should check with XGETBV). Check for XGETBV result AND 0xE6 equals to 0xE6.