AMD Zen 6 Technical Deep Dive 124

AMD Zen 6 Technical Deep Dive

The Venice SoC »

The FP Pipeline


Zen 5 was the generation that rebuilt AMD's floating-point unit, replacing the dual-pumped 256-bit design from Zen 4 with a physical 512-bit datapath. Zen 6 keeps that structure intact and spends its transistor budget on data types instead.

AttributeZen 5 / Zen 5cZen 6 / Zen 6c
AVX-512512-bit data pathSame
FMUL/FMAC + FADD2 pipes + 2 pipesSame
FMAC/FMUL/FADD latency4 / 3 / 2Same
FP16Converts onlyFull AVX-512 FP16 compute
BMMN/ABit Matrix Multiply instructions
VNNI-INT82 pipes4 pipes
VNNI-INT16, BFLOAT162 pipesSame
FP load bandwidth2 loads of any size2x 512-bit or 4x 256-bit loads
FP store bandwidth1x 512-bit or 2x 256-bitSame

Three changes matter here. FP16 moves from conversion-only to full AVX-512 FP16 compute. On Zen 5 a half-precision value had to be widened to FP32, operated on and converted back, which costs instructions and registers and halves the useful lane count; Zen 6 runs FP16 arithmetic natively at 32 lanes per 512-bit register. That is the AVX512-FP16 extension Intel introduced with Sapphire Rapids, now on x86 from both vendors. VNNI INT8 doubles from two pipes to four, which doubles INT8 dot-product throughput per core for quantized inference, the data type most CPU-side LLM work has settled on. BMM, bit matrix multiply, is new. If it follows the classical definition it treats a register as a matrix of bits and multiplies over GF(2), where addition is XOR, which is the primitive behind a surprising amount of cryptography, error-correcting codes, hashing and arbitrary bit permutation. AMD did not say what it expects BMM to be used for, and it is the kind of instruction that appears because some hyperscale customer asked for it early enough.

The FP load path also doubled in the 256-bit case. Zen 5 could issue two FP loads of any width; Zen 6 can issue two 512-bit loads or four 256-bit loads. A lot of real vector code is still 256-bit, and that code now gets twice the load bandwidth. The vector register file holds 384 entries of 512 bits, with 6-wide vector rename. Those pipes set the arithmetic for the HPC numbers quoted later. Two FMA pipes at 512 bits is 16 FP32 lanes each, two operations per lane per cycle, so 64 FP32 FLOPs per core per cycle, exactly as on Zen 5. That is why AMD's DGEMM claim is 1.3x over Turin while its integer claim is 2.0x: dense matrix math is pipe-bound, the pipes did not change, and 1.3x is in line with the step from 192 cores to 256 with no change in per-core throughput. Our inference, not AMD's statement. The 2-cycle FADD deserves a mention in the other direction. It is unusually short, Zen 5 brought it down from 3, and it is what dependent chains of additions in physics and audio code sit waiting on.

New Instructions


The Zen 6 ISA additions go well beyond vectors:
  • Full FP16 support: half-precision as a first-class compute type
  • AVX-VNNI-INT8: more INT8 instructions
  • AVX-NE-CONVERT: conversion between BF16/FP16 and FP32
  • AVX-IFMA: promoted to the VEX encoding
  • BMM: bit matrix multiply
VNNI, Vector Neural Network Instructions, is a dot-product primitive: multiply pairs of INT8 values and accumulate the sums into 32-bit integers in one instruction, which is the inner loop of quantized inference. AVX-NE-CONVERT, the NE being no exceptions, converts between the 16-bit floating-point formats and FP32 without any possibility of raising a floating-point exception, which lets compilers use it freely in mixed-precision code. AVX-IFMA is a 52-bit integer fused multiply-add that borrows the floating-point unit's mantissa multiplier; it exists for big-number arithmetic, RSA and elliptic-curve cryptography above all, and the promotion to the VEX encoding means 256-bit code paths can use it without enabling AVX-512 state. Intel added that encoding on its efficiency cores first; the two vendors now match.

On the kernel and virtualization side:
  • FRED: a new user/kernel interface for interrupts, exceptions and system calls, replacing a mechanism that dates to the 386
  • PML: page modification logging of guest dirty pages
  • PLZA: automatic class-of-service change on privilege level transition
FRED is the one that will matter most to operating system developers. Every interrupt, exception and system call on x86 still goes through a descriptor-table mechanism whose outline dates to the 80386, with the fast SYSCALL path bolted on beside it in the late 1990s. It saves too little state, saves it in the wrong order for a 64-bit kernel, and carries a list of corner cases, nested NMIs and non-canonical return addresses among them, that kernels paper over with hand-written assembly. FRED, Flexible Return and Event Delivery, replaces all of it with a single event delivery path that pushes one complete, consistent frame and returns with one instruction. Intel defined it and Linux gained support in 2024, but a kernel cannot depend on a mechanism only one vendor ships. Zen 6 is AMD's first implementation. PML and PLZA are virtualization plumbing: page modification logging has the hardware record which guest pages were written, which is exactly what live migration needs, instead of the hypervisor trapping on the first write to every page. PLZA ties AMD's quality-of-service controls, which can partition L3 capacity and memory bandwidth between classes of service, to privilege level, so a thread switches class automatically when it enters the kernel; we take that to mean kernel work stops being charged against a tenant's cache budget.

What This Means for Gamers
The FP16 and VNNI INT8 work is aimed at server inference, but it lands on every Zen 6 core. On desktop that mostly matters for local AI that runs on the CPU rather than the GPU or NPU. Doubling INT8 throughput per core is a real gain for small models and for the quantized workloads people run on CPUs today.

Games will not touch BMM or VNNI. The AVX-512 picture barely moves either: the 512-bit datapath and the FADD latency are unchanged from Zen 5, so the emulators and engines that picked up 512-bit vectors on Zen 5 gain little here beyond the general IPC lift.

Security and Profiling
Security gets RMPOPT, a dirty-bit optimization for live migration, and enhanced SMT protection, all under SEV-SNP. The RMP is the reverse map table SNP uses to record which guest owns every physical page, and the slide's wording, improvements for non-secure guests, implies that ordinary unencrypted VMs sharing a host with SNP ones have been paying something for checks against it; RMPOPT is aimed at letting the two kinds coexist without the plain ones subsidizing the secure ones. For performance work, AMD added a memory profiler and buffering for IBS, its instruction-based sampling mechanism, which records what individual instructions did on their way through the pipeline. Buffering the samples instead of interrupting on each one makes profiling cheap enough to leave running in production.
Next Page »The Venice SoC
View as single page
Nov 13th, 2026 17:45 PST change timezone

New Forum Posts

Popular Reviews

TPU on YouTube

Controversial News Posts