# Intel and AMD Publish ACE v2 and AVX10.3, Bringing 4-Bit AI Formats to x86 Years Before the Hardware > Source: > Published: 2026-11-10 13:14:19+00:00 **Intel and AMD have published the ACE v2 and AVX10.3 specifications, adding 4-bit data types and a new set of FP8 and BF16 conversions to x86. GCC patches hit the mailing list the same morning, even though no shipping processor supports the first version of ACE yet.** The x86 Ecosystem Advisory Group, the joint body Intel and AMD set up to stop their instruction sets drifting apart, has posted the next round of its vector and AI extensions. The [combined specification](https://x86ecosystem.org/wp-content/uploads/2026/11/ACE_v2_AVX10_3_Specification_public.pdf) covers two things: ACE v2, the second revision of the AI Compute Extensions, and AVX10.3, the next step for general-purpose vector code. The timing is the interesting part. ACE v1 only [made it into GCC 17 in September](https://hwbusters.com/news/intel-and-amds-ai-compute-extensions-land-in-gcc-17-and-the-flag-is-macev1/), and nothing on sale today runs it. No shipping chip implements AVX10.2 either. So this is a spec for silicon much further out; [Phoronix](https://www.phoronix.com/news/ACE-v2-AVX10.3-Posted), which spotted the release, expects the first CPUs with ACE v2 and AVX10.3 somewhere in the 2028 to 2029 window. ## ACE v2: smaller numbers, more precisions ACE is the matrix side of the house, the part aimed squarely at AI work. Version 2 adds new 4-bit formats and broadens what the 8-bit formats can do. It also brings half precision (FP16), single precision (FP32) and double precision (FP64) modes, which takes the engine beyond pure low-precision inference. The compiler patches show how those precisions are packaged. Intel treats the floating-point outer-product instructions as three separate feature bits, ACE_OP_FP16, ACE_OP_FP32 and ACE_OP_FP64, so a CPU can expose each one independently. The FP64 variant comes with an odd constraint: it needs a register pair that starts on an even-numbered zmm register. The patch notes point out that this resembles the requirements of the long-removed Xeon Phi instructions, which is not a comparison anyone expected to read in 2026. ## AVX10.3: conversions and an interleave AVX10.3 builds on AVX10.2 and is split into four instruction groups. One of them, AVX10V2AUX, is already in GCC trunk. The other three arrive with this patch set: - **INT4/FP4:** packing FP16 and BF16 values down into 4-bit formats. - **BF16 conversions:** FP8 to BF16 up-conversion, plus new BF16 to FP8 down-conversions. - **VPINTERLEAVE:** byte and word interleave operations. At 128 bits they do the same job as the existing vpunpck instructions but only come in EVEX encoding, so GCC quietly emits vpunpck there because it is never larger. Turning on AVX10.3 in the compiler also implies AVX10.2 and AVX10V2AUX, in keeping with AVX10’s idea of stacked, versioned levels instead of a pile of separate feature flags. ## Why it matters The direction is hard to miss: lower precision everywhere. 4-bit weights are already routine in quantized language models running on GPUs and NPUs, and x86 cores have had to unpack them in software. Native INT4 and FP4 handling in both the vector unit and the matrix engine is a clear bid to keep the CPU relevant for local inference, especially in servers where adding a GPU is not on the table. It also shows the advisory group doing what it promised. Both extensions ship as one document under one name, and compiler support is already queued: Intel engineer Haochen Jiang posted the [AVX10.3 series](https://gcc.gnu.org/pipermail/gcc-patches/2026-November/738174.html) and the [ACE v2 series](https://gcc.gnu.org/pipermail/gcc-patches/2026-November/738179.html) within minutes of each other. Whether Intel and AMD ship the hardware in step is a separate question, but for once developers should not have to write for two different answers to the same problem.