Detecting SIMD Support on Intel CPUs with CPUID and XGETBV

April 25, 2000 - By Stefano Tommesani

The original version of this article showed how to detect MMX and the early SSE integer instructions with the CPUID instruction. That was enough in 2000, when the practical question was often: “Can I safely execute MMX or SSE code without crashing on this machine?”

That question is still valid, but the answer has become more complicated.

Modern Intel CPUs may support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, F16C, FMA, AVX2, many AVX-512 subsets, newer AVX-family extensions, AVX10, and AMX matrix extensions. On top of that, the CPU supporting an instruction set is not always enough: for AVX, AVX2, AVX-512, AVX10, and AMX, the operating system must also enable saving and restoring the extended register state used by those instructions.

This article shows how to think about SIMD feature detection on Intel CPUs today, how to use CPUID, when to use XGETBV, and how to organize runtime dispatch so that your application selects the fastest implementation it can safely run.

Why feature detection still matters

It is tempting to assume that every modern x86 CPU supports the instruction set you want to use. In many limited cases that assumption may be good enough. For example, 64-bit x86 operating systems effectively make SSE2 a baseline. But real-world software often runs in more varied environments:

32-bit builds may still run on old processors.
Virtual machines may hide CPU features.
Operating systems may not enable all extended register states.
AVX-512 support differs significantly between CPU generations.
Some Intel client CPUs support AVX2 but not AVX-512.
Some server CPUs support AVX-512, but only specific AVX-512 subsets.
AMX may require both hardware support and explicit operating-system permission.

The safe rule is simple: before executing instructions from a SIMD extension, check that the feature is available to the current process.

The detection result is not just a property of the silicon. It is the combination of CPU, BIOS/firmware, operating system, virtual machine, and process permissions.

CPUID in one paragraph

CPUID is the x86 instruction used to query processor capabilities. You place a function number, usually called a leaf, in EAX, sometimes a subleaf in ECX, execute CPUID, and read the returned values from EAX, EBX, ECX, and EDX.

For old SIMD features such as MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, and SSE4.2, the feature bit reported by CPUID is usually enough.

For AVX and anything that uses wider or newer architectural state, it is not enough. You must also verify that the operating system enables the required state with XGETBV.

Why AVX detection needs XGETBV

SSE uses XMM registers. AVX extends this with YMM registers. AVX-512 extends this again with ZMM registers and opmask registers. AMX adds tile state.

A CPU may support these instructions, but if the operating system does not save and restore the corresponding state during context switches, user-mode code cannot safely use them. That is why AVX detection must check both:

CPU support reported by CPUID.
OS support reported by OSXSAVE and XGETBV.

For AVX and AVX2, the operating system must enable XMM and YMM state.

For AVX-512, the operating system must also enable opmask and ZMM state.

For AMX, the processor exposes tile state, and the operating system may require the application to request permission before using it.

The SIMD instruction-set families on Intel CPUs

Intel SIMD support is best understood as a set of generations.

Family	Instruction sets / extensions	Notes
Legacy SIMD	MMX	64-bit integer SIMD using MMX registers aliased with x87 state. Mostly obsolete today.
SSE family	SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2	128-bit XMM-based SIMD. SSE2 is the practical baseline for x86-64 code.
AVX family	AVX, F16C, FMA, AVX2	256-bit YMM-based SIMD. Requires OS support for extended state.
Newer AVX-family extensions	AVX_VNNI, AVX_VNNI_INT8, AVX_NE_CONVERT, AVX_IFMA, AVX_VNNI_INT16	Newer VEX/EVEX vector extensions aimed especially at AI, integer dot products, conversion, and multiply-add workloads. Availability varies by generation.
Crypto/vector helpers	AES, PCLMULQDQ, VAES, VPCLMULQDQ, GFNI, SHA, SHA512, SM3, SM4	Not all of these are “SIMD” in the narrow arithmetic sense, but they are commonly detected alongside vector code paths.
AVX-512 family	AVX-512F, AVX-512CD, AVX-512BW, AVX-512DQ, AVX-512VL, AVX-512IFMA52, AVX-512VBMI, AVX-512VBMI2, AVX-512VNNI, AVX-512BITALG, AVX-512VPOPCNTDQ, AVX-512BF16, AVX-512FP16, AVX-512VP2INTERSECT, AVX-512PF, AVX-512ER, AVX-512_4VNNIW, AVX-512_4FMAPS	AVX-512 is not one feature. It is a family of independently enumerated extensions.
AVX10	AVX10.1, AVX10.2 and later	Intel’s converged vector ISA direction. Detection is version-based rather than checking a long list of unrelated AVX-512 feature flags.
AMX family	AMX-TILE, AMX-INT8, AMX-BF16, AMX-FP16, AMX-COMPLEX	Matrix/tile extensions rather than classic lane-based SIMD, but relevant for modern Intel vector and AI dispatch.

The important point is that the feature names are not just marketing names. They usually correspond to specific CPUID bits, and production code should test the exact feature required by the implementation it is about to call.

Common CPUID feature locations

The following table lists the common locations you will check when building SIMD dispatch code.

Feature	CPUID location	Extra OS check
MMX	`CPUID.1:EDX[23]`	No
SSE	`CPUID.1:EDX[25]`	Usually no in user-mode apps
SSE2	`CPUID.1:EDX[26]`	Usually no in user-mode apps
SSE3	`CPUID.1:ECX[0]`	No
PCLMULQDQ	`CPUID.1:ECX[1]`	No
SSSE3	`CPUID.1:ECX[9]`	No
FMA	`CPUID.1:ECX[12]`	AVX OS state
SSE4.1	`CPUID.1:ECX[19]`	No
SSE4.2	`CPUID.1:ECX[20]`	No
AES	`CPUID.1:ECX[25]`	No
XSAVE	`CPUID.1:ECX[26]`	Required before `XGETBV` logic
OSXSAVE	`CPUID.1:ECX[27]`	Required before calling `XGETBV`
AVX	`CPUID.1:ECX[28]`	XMM + YMM enabled in XCR0
F16C	`CPUID.1:ECX[29]`	AVX OS state
AVX2	`CPUID.7.0:EBX[5]`	AVX OS state
AVX-512F	`CPUID.7.0:EBX[16]`	AVX-512 OS state
AVX-512DQ	`CPUID.7.0:EBX[17]`	AVX-512 OS state
AVX-512IFMA	`CPUID.7.0:EBX[21]`	AVX-512 OS state
AVX-512PF	`CPUID.7.0:EBX[26]`	AVX-512 OS state
AVX-512ER	`CPUID.7.0:EBX[27]`	AVX-512 OS state
AVX-512CD	`CPUID.7.0:EBX[28]`	AVX-512 OS state
AVX-512BW	`CPUID.7.0:EBX[30]`	AVX-512 OS state
AVX-512VL	`CPUID.7.0:EBX[31]`	AVX-512 OS state
AVX-512VBMI	`CPUID.7.0:ECX[1]`	AVX-512 OS state
AVX-512VBMI2	`CPUID.7.0:ECX[6]`	AVX-512 OS state
GFNI	`CPUID.7.0:ECX[8]`	Depends on encoding used
VAES	`CPUID.7.0:ECX[9]`	AVX/AVX-512 depending on code path
VPCLMULQDQ	`CPUID.7.0:ECX[10]`	AVX/AVX-512 depending on code path
AVX-512VNNI	`CPUID.7.0:ECX[11]`	AVX-512 OS state
AVX-512BITALG	`CPUID.7.0:ECX[12]`	AVX-512 OS state
AVX-512VPOPCNTDQ	`CPUID.7.0:ECX[14]`	AVX-512 OS state
AVX-512_4VNNIW	`CPUID.7.0:EDX[2]`	AVX-512 OS state
AVX-512_4FMAPS	`CPUID.7.0:EDX[3]`	AVX-512 OS state
AVX-512VP2INTERSECT	`CPUID.7.0:EDX[8]`	AVX-512 OS state
AMX-BF16	`CPUID.7.0:EDX[22]`	AMX OS state and possibly permission
AVX-512FP16	`CPUID.7.0:EDX[23]`	AVX-512 OS state
AMX-TILE	`CPUID.7.0:EDX[24]`	AMX OS state and possibly permission
AMX-INT8	`CPUID.7.0:EDX[25]`	AMX OS state and possibly permission
AVX-VNNI	`CPUID.7.1:EAX[4]`	AVX OS state
AVX-512BF16	`CPUID.7.1:EAX[5]`	AVX-512 OS state
AVX10	`CPUID.7.1:EDX[19]`, then `CPUID.24H`	AVX10/AVX-512-class OS state

Newer extensions continue to appear, so the most future-proof approach is not to freeze this table forever. Treat it as the structure of the solution, then verify new bit positions against the current Intel Software Developer’s Manual or Intel Intrinsics Guide when adding a new code path.

A modern C++ feature detector

The following example uses compiler intrinsics instead of inline assembly. That matters because Microsoft’s 64-bit compiler does not support inline assembly, and because compiler intrinsics make the code easier to port between MSVC, GCC, and Clang.

This code detects the most common Intel SIMD feature sets and separates CPU support from operating-system support for AVX, AVX-512, AVX10, and AMX.

#include <cstdint>
#include <cstdio>

#if defined(_MSC_VER)
    #include <intrin.h>
#else
    #include <cpuid.h>
#endif

struct CpuIdRegs
{
    uint32_t eax;
    uint32_t ebx;
    uint32_t ecx;
    uint32_t edx;
};

static CpuIdRegs cpuid(uint32_t leaf, uint32_t subleaf = 0)
{
#if defined(_MSC_VER)
    int regs[4] = {};
    __cpuidex(regs, static_cast<int>(leaf), static_cast<int>(subleaf));
    return {
        static_cast<uint32_t>(regs[0]),
        static_cast<uint32_t>(regs[1]),
        static_cast<uint32_t>(regs[2]),
        static_cast<uint32_t>(regs[3])
    };
#else
    uint32_t eax = 0, ebx = 0, ecx = 0, edx = 0;
    __cpuid_count(leaf, subleaf, eax, ebx, ecx, edx);
    return { eax, ebx, ecx, edx };
#endif
}

static uint64_t xgetbv0()
{
#if defined(_MSC_VER)
    return _xgetbv(0);
#else
    uint32_t eax = 0, edx = 0;
    __asm__ volatile("xgetbv" : "=a"(eax), "=d"(edx) : "c"(0));
    return (static_cast<uint64_t>(edx) << 32) | eax;
#endif
}

static bool bit(uint32_t value, unsigned index)
{
    return ((value >> index) & 1u) != 0;
}

struct SimdFeatures
{
    bool mmx = false;
    bool sse = false;
    bool sse2 = false;
    bool sse3 = false;
    bool ssse3 = false;
    bool sse41 = false;
    bool sse42 = false;

    bool pclmulqdq = false;
    bool aes = false;

    bool avx = false;
    bool f16c = false;
    bool fma = false;
    bool avx2 = false;
    bool avx_vnni = false;

    bool gfni = false;
    bool vaes = false;
    bool vpclmulqdq = false;

    bool avx512f = false;
    bool avx512dq = false;
    bool avx512ifma = false;
    bool avx512pf = false;
    bool avx512er = false;
    bool avx512cd = false;
    bool avx512bw = false;
    bool avx512vl = false;
    bool avx512vbmi = false;
    bool avx512vbmi2 = false;
    bool avx512vnni = false;
    bool avx512bitalg = false;
    bool avx512vpopcntdq = false;
    bool avx512_4vnniw = false;
    bool avx512_4fmaps = false;
    bool avx512_vp2intersect = false;
    bool avx512bf16 = false;
    bool avx512fp16 = false;

    bool amx_tile = false;
    bool amx_int8 = false;
    bool amx_bf16 = false;

    bool avx10 = false;
    uint32_t avx10_version = 0;
    bool avx10_256 = false;
    bool avx10_512 = false;
};

static SimdFeatures detectSimdFeatures()
{
    SimdFeatures f;

    const CpuIdRegs leaf0 = cpuid(0);
    const uint32_t maxBasicLeaf = leaf0.eax;

    if (maxBasicLeaf < 1)
        return f;

    const CpuIdRegs leaf1 = cpuid(1);

    f.mmx        = bit(leaf1.edx, 23);
    f.sse        = bit(leaf1.edx, 25);
    f.sse2       = bit(leaf1.edx, 26);

    f.sse3       = bit(leaf1.ecx, 0);
    f.pclmulqdq  = bit(leaf1.ecx, 1);
    f.ssse3      = bit(leaf1.ecx, 9);
    f.fma        = bit(leaf1.ecx, 12);
    f.sse41      = bit(leaf1.ecx, 19);
    f.sse42      = bit(leaf1.ecx, 20);
    f.aes        = bit(leaf1.ecx, 25);

    const bool cpuXsave   = bit(leaf1.ecx, 26);
    const bool osXsave    = bit(leaf1.ecx, 27);
    const bool cpuAvx     = bit(leaf1.ecx, 28);
    const bool cpuF16c    = bit(leaf1.ecx, 29);

    uint64_t xcr0 = 0;

    if (cpuXsave && osXsave)
        xcr0 = xgetbv0();

    // XCR0 bit 1 = XMM state, bit 2 = YMM upper state.
    const bool osAvxState = (xcr0 & 0x6) == 0x6;

    // XCR0 bits 5, 6, 7 are required for AVX-512 opmask/ZMM state.
    // Together with XMM and YMM, the useful AVX-512 mask is 0xE6.
    const bool osAvx512State = (xcr0 & 0xE6) == 0xE6;

    // XCR0 bits 17 and 18 are AMX tile config and tile data.
    const bool osAmxState = (xcr0 & ((1ull << 17) | (1ull << 18))) ==
                            ((1ull << 17) | (1ull << 18));

    f.avx  = cpuAvx && osAvxState;
    f.f16c = cpuF16c && osAvxState;
    f.fma  = f.fma && osAvxState;

    CpuIdRegs leaf7_0 = {};
    CpuIdRegs leaf7_1 = {};
    CpuIdRegs leaf24_0 = {};

    if (maxBasicLeaf >= 7)
    {
        leaf7_0 = cpuid(7, 0);
        const uint32_t maxLeaf7Subleaf = leaf7_0.eax;

        f.avx2 = bit(leaf7_0.ebx, 5) && osAvxState;

        f.avx512f     = bit(leaf7_0.ebx, 16) && osAvx512State;
        f.avx512dq    = bit(leaf7_0.ebx, 17) && osAvx512State;
        f.avx512ifma  = bit(leaf7_0.ebx, 21) && osAvx512State;
        f.avx512pf    = bit(leaf7_0.ebx, 26) && osAvx512State;
        f.avx512er    = bit(leaf7_0.ebx, 27) && osAvx512State;
        f.avx512cd    = bit(leaf7_0.ebx, 28) && osAvx512State;
        f.avx512bw    = bit(leaf7_0.ebx, 30) && osAvx512State;
        f.avx512vl    = bit(leaf7_0.ebx, 31) && osAvx512State;

        f.avx512vbmi       = bit(leaf7_0.ecx, 1)  && osAvx512State;
        f.avx512vbmi2      = bit(leaf7_0.ecx, 6)  && osAvx512State;
        f.gfni             = bit(leaf7_0.ecx, 8);
        f.vaes             = bit(leaf7_0.ecx, 9)  && osAvxState;
        f.vpclmulqdq       = bit(leaf7_0.ecx, 10) && osAvxState;
        f.avx512vnni       = bit(leaf7_0.ecx, 11) && osAvx512State;
        f.avx512bitalg     = bit(leaf7_0.ecx, 12) && osAvx512State;
        f.avx512vpopcntdq  = bit(leaf7_0.ecx, 14) && osAvx512State;

        f.avx512_4vnniw       = bit(leaf7_0.edx, 2)  && osAvx512State;
        f.avx512_4fmaps       = bit(leaf7_0.edx, 3)  && osAvx512State;
        f.avx512_vp2intersect = bit(leaf7_0.edx, 8)  && osAvx512State;

        f.amx_bf16 = bit(leaf7_0.edx, 22) && osAmxState;
        f.avx512fp16 = bit(leaf7_0.edx, 23) && osAvx512State;
        f.amx_tile = bit(leaf7_0.edx, 24) && osAmxState;
        f.amx_int8 = bit(leaf7_0.edx, 25) && osAmxState;

        if (maxLeaf7Subleaf >= 1)
        {
            leaf7_1 = cpuid(7, 1);

            f.avx_vnni   = bit(leaf7_1.eax, 4) && osAvxState;
            f.avx512bf16 = bit(leaf7_1.eax, 5) && osAvx512State;

            // AVX10 enable bit.
            f.avx10 = bit(leaf7_1.edx, 19) && osAvx512State;
        }
    }

    if (f.avx10 && maxBasicLeaf >= 0x24)
    {
        leaf24_0 = cpuid(0x24, 0);

        f.avx10_version = leaf24_0.ebx & 0xff;
        f.avx10_256 = bit(leaf24_0.ebx, 17);
        f.avx10_512 = bit(leaf24_0.ebx, 18);
    }

    return f;
}

int main()
{
    const SimdFeatures f = detectSimdFeatures();

    std::printf("MMX:        %s\n", f.mmx ? "yes" : "no");
    std::printf("SSE:        %s\n", f.sse ? "yes" : "no");
    std::printf("SSE2:       %s\n", f.sse2 ? "yes" : "no");
    std::printf("SSE3:       %s\n", f.sse3 ? "yes" : "no");
    std::printf("SSSE3:      %s\n", f.ssse3 ? "yes" : "no");
    std::printf("SSE4.1:     %s\n", f.sse41 ? "yes" : "no");
    std::printf("SSE4.2:     %s\n", f.sse42 ? "yes" : "no");
    std::printf("AVX:        %s\n", f.avx ? "yes" : "no");
    std::printf("F16C:       %s\n", f.f16c ? "yes" : "no");
    std::printf("FMA:        %s\n", f.fma ? "yes" : "no");
    std::printf("AVX2:       %s\n", f.avx2 ? "yes" : "no");
    std::printf("AVX-VNNI:   %s\n", f.avx_vnni ? "yes" : "no");
    std::printf("AVX-512F:   %s\n", f.avx512f ? "yes" : "no");
    std::printf("AVX-512BW:  %s\n", f.avx512bw ? "yes" : "no");
    std::printf("AVX-512DQ:  %s\n", f.avx512dq ? "yes" : "no");
    std::printf("AVX-512VL:  %s\n", f.avx512vl ? "yes" : "no");
    std::printf("AVX-512VNNI:%s\n", f.avx512vnni ? "yes" : "no");
    std::printf("AVX-512BF16:%s\n", f.avx512bf16 ? "yes" : "no");
    std::printf("AVX-512FP16:%s\n", f.avx512fp16 ? "yes" : "no");

    if (f.avx10)
    {
        std::printf("AVX10:      yes, version %u, 256=%s, 512=%s\n",
            f.avx10_version,
            f.avx10_256 ? "yes" : "no",
            f.avx10_512 ? "yes" : "no");
    }
    else
    {
        std::printf("AVX10:      no\n");
    }

    std::printf("AMX-TILE:   %s\n", f.amx_tile ? "yes" : "no");
    std::printf("AMX-INT8:   %s\n", f.amx_int8 ? "yes" : "no");
    std::printf("AMX-BF16:   %s\n", f.amx_bf16 ? "yes" : "no");

    return 0;
}

This is intentionally explicit. In production code, you may prefer to wrap these tests behind functions such as hasAVX2(), hasAVX512BW(), or hasAMXINT8(), but keeping the mapping visible makes it easier to audit.

Choosing the right dispatch order

Feature detection is normally used to choose between multiple implementations of the same algorithm.

For example:

using FilterFunction = void (*)(const uint8_t* src, uint8_t* dst, int count);

FilterFunction chooseFilterImplementation()
{
    const SimdFeatures f = detectSimdFeatures();

    if (f.avx10 && f.avx10_version >= 2 && f.avx10_512)
        return filter_avx10_512;

    if (f.avx512f && f.avx512bw && f.avx512vl)
        return filter_avx512;

    if (f.avx2)
        return filter_avx2;

    if (f.sse42)
        return filter_sse42;

    if (f.sse2)
        return filter_sse2;

    return filter_scalar;
}

The exact order depends on the workload. The newest instruction set is not always automatically the fastest. AVX-512 may offer much higher throughput for some kernels, but on some processors heavy AVX-512 code can affect frequency. AVX2 may be the best general-purpose target for many desktop and laptop systems. SSE2 remains useful as a conservative fallback.

Always benchmark the actual kernel on representative machines.

Do not assume feature hierarchy

It is common to think of instruction sets as a simple ladder:

MMX → SSE → SSE2 → SSE3 → SSSE3 → SSE4 → AVX → AVX2 → AVX-512

That is a useful mental model, but it is not precise enough for feature detection.

Some features are separate flags. Some are optional subsets. AVX-512 in particular is a collection of many extensions. A CPU that supports AVX-512F does not automatically support AVX-512BW, AVX-512VL, AVX-512VNNI, AVX-512BF16, or AVX-512FP16.

Your code should check the exact instructions it uses.

For example, if an implementation uses byte and word operations in AVX-512 registers, check AVX-512BW. If it uses AVX-512 instructions with 128-bit or 256-bit vectors, check AVX-512VL. If it uses VNNI dot-product instructions, check AVX-512VNNI or AVX-VNNI depending on the encoding used by your implementation.

AMX is not just another SIMD flag

AMX deserves special care. It is related to high-throughput numeric code, but it is not classic lane-based SIMD like SSE, AVX, or AVX-512. AMX uses tile registers and tile instructions intended for matrix operations.

Detecting AMX hardware support is not enough. You must also consider:

Whether the operating system enables AMX state.
Whether the process has permission to use tile data state.
Whether the compiler, assembler, runtime, and OS headers support the AMX instructions you want to use.

On Linux, user-mode applications may need to request access to tile data state before executing AMX instructions. A CPUID check alone is therefore not a complete AMX readiness check.

In practice, AMX dispatch should be isolated behind a carefully tested initialization path. If AMX initialization fails, fall back to AVX-512, AVX2, or scalar code.

AVX10 changes the detection model

AVX-512 grew into a large set of separate feature bits. That gives software precise control, but it also makes dispatch code complicated.

AVX10 moves toward a versioned model. Instead of checking a long list of unrelated AVX-512 feature flags, software can check whether AVX10 is present, then read the AVX10 version and supported vector lengths.

Conceptually, AVX10 detection looks like this:

if (hasAVX10())
{
    const int version = getAVX10Version();

    if (version >= 2 && hasAVX10_512())
    {
        // Use an AVX10.2 512-bit implementation.
    }
    else if (version >= 2 && hasAVX10_256())
    {
        // Use an AVX10.2 256-bit implementation.
    }
}

That does not mean legacy AVX-512 detection disappears immediately. Existing software still needs to detect AVX-512 feature flags for current and older CPUs. But new code should be designed so that AVX10 can become another dispatch target without rewriting the whole detection layer.

Inline assembly vs compiler intrinsics

The original MMX/SSE detection code used inline assembly. That was normal for C and C++ code at the time.

Today, compiler intrinsics are usually better:

They work in 64-bit builds.
They are easier to read.
They are less compiler-specific than inline assembly.
They allow the compiler to understand what the code is doing.
They make it easier to keep detection code in normal C++ files.

For MSVC, use __cpuid, __cpuidex, and _xgetbv.

For GCC and Clang, use __cpuid_count from <cpuid.h> or compiler-provided CPU feature helpers where appropriate.

Compiler feature helpers

Some compilers and libraries provide higher-level feature checks. Examples include compiler built-ins, CPU dispatch attributes, target_clones, Intel libraries, and platform-specific APIs.

These can be useful, but it is still important to understand the underlying rules:

CPUID feature bits tell you what the CPU or virtual CPU exposes.
AVX and later also require OS-enabled register state.
AVX-512 requires additional state beyond AVX.
AMX may require explicit OS permission.
Some features are independent; do not infer them from a broader family name.

High-level helpers are convenient, but they are not a substitute for knowing what your code path actually uses.

Practical recommendations

For modern Intel SIMD dispatch, I recommend the following structure:

Always provide a scalar fallback.
Use SSE2 as the conservative x86-64 baseline.
Add SSE4.1 or SSE4.2 paths only when they materially simplify or accelerate the algorithm.
Use AVX only when 256-bit floating-point operations help.
Use AVX2 as the common high-performance baseline for modern integer SIMD.
Use FMA and F16C as separate feature checks when your code uses those instructions.
Treat AVX-512 as a collection of features, not as one flag.
Treat AMX as a separate initialization and permission problem, not just a CPUID bit.
Add AVX10 as a versioned dispatch path when targeting future Intel CPUs.
Benchmark every path. Wider vectors are not automatically faster for every workload.

Conclusion

Detecting MMX and SSE used to require only a few CPUID bits. Modern Intel SIMD detection requires a more disciplined approach.

For MMX and SSE-family code, CPUID feature bits are usually enough. For AVX and AVX2, check CPUID and verify that the operating system enables XMM and YMM state with XGETBV. For AVX-512, also verify opmask and ZMM state. For AMX, check the hardware flags, the extended state, and any operating-system permission requirements. For AVX10, be ready for version-based detection.

The safest design is to keep feature detection centralized, dispatch only to code paths whose exact requirements are satisfied, and always keep a fallback implementation. That way your program can run correctly on old machines, modern laptops, servers, virtual machines, and future Intel CPUs without relying on assumptions that may not hold.