perf(cpu/matmul): AVX-512 VNNI for Q8_0 outer-product (AvxVnni.V512 / VPDPBUSD-512) — requires .NET 11 bump

[jamesburton]

The AVX-512 VNNI path for Q8_0 requires .NET 11

The Q8_0 outer-product kernel's AVX-512 path (OuterProductQ8_0Avx512_4x6 → helper Avx512DualBlockFma, plus the single-dot VecDotQ8_0Avx512 and ProcessAvx512DualBlock) currently reduces int8 with Avx2.Sign + MultiplyAddAdjacent (maddubs) + MultiplyAddAdjacent(prod, ones256) on two 256-bit halves, then assembles Vector512<float> for the accumulate. It does not use VNNI. Replacing that with a single 512-bit VPDPBUSD (drop ones256 + prod) is the win — but it cannot be expressed on the current target.

Why not on net10.0 (SDK 10.0.300) — verified empirically

• System.Runtime.Intrinsics.X86.Avx512Vnni does not exist in this SDK (clean-project CS0246; reflection on System.Private.CoreLib returns null; the only *Vnni* types are AvxVnni, AvxVnniInt8, AvxVnniInt16). The BCL deliberately did not ship a standalone Avx512Vnni class.
• The only 512-bit VPDPBUSD available in net10.0 is AvxVnniInt8.V512.MultiplyWideningAndAdd, but it is gated on AVX_VNNI_INT8 (Granite Rapids / Sierra Forest / AVX10.2-era) — a different flag from AVX512-VNNI. It returns IsSupported == false on Zen4, Zen5, Ice Lake-SP, Sapphire Rapids, so it would silently fall back to maddubs on every intended target (and skip its own parity test even on a Zen5 box).

The route — AvxVnni.V512 (.NET 11)

dotnet/runtime#128365 (merged 2026-06-09) adds AvxVnni.V512.MultiplyWideningAndAdd(Vector512<int>, Vector512<byte>, Vector512<sbyte>) -> Vector512<int>. It maps to the AVX512v3 instruction-set group (BITALG+VBMI2+VPOPCNTDQ+VNNI), i.e. standard AVX512-VNNI (CPUID leaf 7 ECX bit 11) — so AvxVnni.V512.IsSupported is true on AMD Zen5 / Strix Halo and on Intel Cascade/Ice/Sapphire. It ships in .NET 11 and is absent from net10.0.

Scope (gated on the .NET 11 bump)

1. Bump Directory.Build.props TFM → net11.0, global.json SDK pin.
2. Rewrite the AVX-512 Q8_0 int8 reduction (the three sites above) to a single AvxVnni.V512.MultiplyWideningAndAdd(Vector512<int>.Zero, absX512.AsByte(), adjW512) over Vector512 — 64 int8 → 16 int32. The dual-block scale mapping (lanes 0–7 → block0, 8–15 → block1) is unchanged. Drop ones256.
3. Gate on AvxVnni.V512.IsSupported; keep the maddubs-on-256-halves path as the AVX-512-without-VNNI fallback.
4. Parity tests vs scalar (discriminating shapes), guarded by AvxVnni.V512.IsSupported — run on Zen5 / AVX-512 CI.
5. Benchmark V512-VNNI vs the current AVX-512 maddubs path on Strix Halo (Zen5).

Until then

The net10.0 deliverable is #321 / PR #323 (the V256 AvxVnni path for AVX2+VNNI-without-AVX512 CPUs — benchmarked ~1.3–1.6× on Meteor Lake). On AVX-512 CPUs the existing 512-bit maddubs path remains in use until this lands.

References

• perf(cpu/matmul): Q8_0 outer-product GEMM via AVX2 VNNI (VPDPBUSD-256) — unblock #61 register pressure #321 / PR perf(cpu/matmul): Q8_0 outer-product GEMM via AVX2 VNNI (VPDPBUSD-256) — unblock #61 register pressure #323 — V256 VNNI Q8_0 kernel (net10.0)
• Add AvxVnni.V512 hardware intrinsics dotnet/runtime#128365 — AvxVnni.V512 (AVX512-VNNI / AVX512v3, .NET 11)

[jamesburton]

Benchmark result (AMD Zen5 / Strix Halo) — AVX-512 VNNI is a regression here

Ran the A/B on Zen5 against a locally-built .NET 11 runtime (AvxVnni.V512 from dotnet/runtime#128365), via BenchmarkDotNet's CoreRun toolchain on the dev CoreCLR. Quiet machine, clean variance ([Host]: .NET 11.0.0, X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI).

Kernel — Q8_0 4×6 outer-product, K=4096	Mean	Ratio
Avx512_4x6_Maddubs (baseline: maddubs+madd(ones) on 256-bit halves)	3.219 µs	1.00
Avx512_4x6_Vnni (AvxVnni.V512.MultiplyWideningAndAdd, VPDPBUSD-512)	4.599 µs	1.43× slower

(CoreRun job, 30 iterations / 10 warmup, RatioSD 0.10, StdDev ~5%.)

Why VNNI loses here

1. Q8_0's per-block fp16 scales force a convert→scale→FMA after every 32-element block, so VNNI's signature advantage — long int32 accumulation chains across many blocks — can't be used. Each block is a lone VPDPBUSD.
2. Blocks aren't contiguous 64 bytes (a scale sits between them), so the V512 path pays two extra Vector256→Vector512 inserts per cell to assemble absX512/adjW512 — overhead the half-width maddubs path avoids.
3. Zen5 executes the 256-bit maddubs+madd pair with more throughput/ILP than one serial 512-bit VPDPBUSD.

Contrast with #321

The 256-bit AVX-VNNI path (#321) measured ~1.3–1.6× faster on Intel Meteor Lake — but that's a different kernel/bit-width/µarch, and on AVX-512 CPUs the dispatch already prefers the 512-bit maddubs path, so #321 never runs on Zen5.

Conclusion

The AVX-512 VNNI path as-implemented is not worth a .NET 11 migration — the existing maddubs AVX-512 kernel is already faster on Zen5. Leaving this open as a documented negative result. A different VNNI formulation might help, but Q8_0's per-block scaling fundamentally caps the upside. (Parity vs scalar was not re-run in this pass; moot for the perf decision, but worth confirming before any reuse.)

[jamesburton]

Correctness confirmed + a runtime-pack gotcha worth recording

Ran the gated V512 parity tests on Zen5 with the IsSupported guards forced open (so a skip can't masquerade as a pass): 9/9 pass — OuterProductQ8_0Avx512Vnni_4x6 is numerically correct vs the scalar reference across all discriminating shapes (block counts 1 / 2 / 3 / 8 / 17 / 18 / 48 / 128, plus the discrimination self-check).

So the kernel is correct — just 1.43× slower. A clean negative result, fully characterised.

Gotcha: the shipping runtime pack reports the new ISA as unsupported

The first parity attempts threw PlatformNotSupportedException on Zen5. Root cause: the shipping Microsoft.NETCore.App.Runtime.win-x64.11.0.0-dev pack reports AvxVnni.V512.IsSupported == false even on AVX512-VNNI hardware. Only the test Core_Root (freshly-built coreclr + IL System.Private.CoreLib, used by corerun) reports the new ISA correctly — which is exactly why the BenchmarkDotNet --coreRun run worked but a plain self-contained run did not. DOTNET_ReadyToRun=0 alone did not fix it; overlaying Core_Root's coreclr.dll / clrjit.dll / System.Private.CoreLib.dll over the published output did.

Takeaway for exercising a brand-new intrinsic from an external app: run via corerun/Core_Root (or the binary-overlay), not the shipping pack.

[jamesburton]

Zero-point 512-native VNNI — the regression was an implementation artifact

The first kernel's 1.43× slowdown was not fundamental. It came from per-cell Vector256→Vector512 packing + the 256-bit-only vpsignb sign trick. A 512-native rewrite using the zero-point (+128) compensation method — u = x XOR 0x80 (unsigned, hoisted per-token), VPDPBUSD(u, raw_signed_w) (weights + Σw hoisted per-row), deferred −128·Σw correction in the float domain — removes all 48 Avx2.Sign/block-pair and the per-cell packs.

3-way on AMD Zen5 / Strix Halo (BenchmarkDotNet CoreRun, 30 iter / 10 warmup; parity 17/17 across all variants):

Q8_0 4×6 outer-product, K=4096	Mean	vs maddubs
Avx512_4x6_Maddubs (baseline)	3.508 µs	1.00
Avx512_4x6_Vnni (sign-trick, per-cell packs)	4.708 µs	1.34× slower
Avx512_4x6_VnniZp (zero-point, hoisted)	3.370 µs	~0.96×

So the zero-point kernel reaches statistical parity with maddubs — the ~4% edge is within noise (StdDevs overlap; the maddubs baseline itself drifts ~9% run-to-run).

Updated verdict

VNNI is not fundamentally behind on Zen5 for Q8_0 — properly implemented it matches maddubs. It doesn't clearly win either: Q8_0's per-block fp16 scales cap VNNI's int32-accumulation advantage, and Zen5's 256-bit maddubs+madd throughput is already strong. No reason to ship it over maddubs today, but it's a viable, competitive path and a clean baseline for when more 512-bit ops (or a scale-separated data layout that drops the remaining hoisted vinserts) open further fusion/reuse. Keeping this open as the tracked baseline.

(Earlier "1.43×/1.36× slower" figures were the naive sign-trick kernel; superseded by this three-way.)

[jamesburton]

AVX-512 BF16 Q8_0 microkernel — measured 4-way, and it wins

The fourth Q8_0 4×6 outer-product variant (Avx512_4x6_Bf16 — dequantize each Q8_0 block to bf16 with the
per-block scale folded into the value, then accumulate with VDPBF16PS into one fp32 accumulator) is now
measurable, after the Avx512Bf16 intrinsic landed in dotnet/runtime plus three JIT fixes (codegen dispatch,
a FullOpts EVEX encoding bug for zmm16–31, and V512VersionOfIsa wiring that also re-enabled AvxVnni.V512).
All four variants now run on a single runtime build, so this is an apples-to-apples comparison.

Benchmark — 4×6 Q8_0 outer-product tile, K=4096, CoreRun, 30 iter, Zen5 (Ryzen AI Max / Strix Halo)

Kernel	Mean	Ratio vs maddubs
Avx512_4x6_Maddubs (baseline)	4.06 µs	1.00
Avx512_4x6_Vnni (VPDPBUSD, sign-trick)	5.20 µs	1.33 (slower)
Avx512_4x6_VnniZp (VPDPBUSD, zero-point)	3.84 µs	0.98 (~parity)
Avx512_4x6_Bf16 (VDPBF16PS)	1.67 µs	0.43 (≈2.3× faster)

BF16 is ~2.3× faster than the best integer kernel (VnniZp 3.84 µs → BF16 1.67 µs = 2.29×; vs maddubs
2.4×). This reproduces the earlier VNNI finding (sign-trick ~1.33× slower, zero-point ~parity with maddubs) and
adds BF16 as the clear winner. The maddubs baseline is somewhat noisy on this laptop (multimodal, thermal), but
BF16's mean sits well below every integer kernel's mean. This is a microkernel measurement (one 4×6 tile),
not end-to-end inference.

Why it wins: folding the scale into the bf16 value makes the inner loop a pure VDPBF16PS chain into a
single fp32 accumulator — no per-block integer reduction, no vpmaddwd-with-ones, no dual-scale fold that the
int kernels pay every 32-element block. Fewer inner-loop instructions outweighs bf16's 2× element width.

Correctness

Full outer-product parity vs the scalar oracle: 100/0/0 with every V512 guard forced open (maddubs, both
VNNI variants, and BF16 all execute for real). BF16 specifically: 8/8 across blockCount ∈ {1,2,3,8,17,18,48,128} (K up to 4096), within a bf16-appropriate tolerance |bf16 − scalar| ≤ 3e-2·(tile-max|scalar| + 1e-3).

End-to-end perplexity (SmolLM-135M Q8_0, Strix/Zen5, net11 + Core_Root)

The microkernel caveat below is now answered end-to-end. Three Q8_0 prefill reductions on the same passage
(32 scored tokens), measured in one process:

Prefill path	Perplexity	vs inner-product baseline
inner-product (cache-tiled — the production default)	26.2386	—
integer outer-product (R4 maddubs)	26.1375	−0.39%
bf16 outer-product (VDPBF16PS)	26.6587	+1.60%

Two things matter here:

1. The outer-product restructuring itself is free. Integer-outer vs the inner-product default is −0.39%
   (within FP rounding — both match exact scalar Q8_0 truth to ~1e-4). Switching from inner-product to the
   R4 outer-product GEMM costs no model quality.
2. BF16's end-to-end cost, anchored against the production baseline, is +1.60% perplexity for the ~2.3×
   microkernel speed. (Measured against integer-outer alone it reads +1.99%, but integer-outer happens to sit
   slightly below the true baseline, so +1.60% is the honest figure vs what users actually run today.)

Logits agree to a scale-normalized 3.2e-2 (vec-scale gate); per-element relative diff is large only on
near-zero cancellation logits, as expected for a correct bf16 kernel. Parity of the integer outer-product path
vs inner-product is 3/3 PASS (scaleNormDiff 3.4e-7 / 1.98e-2 / 2.28e-2 for n=2/10/4 tokens).

End-to-end prefill speed (Llama-3.2-1B Q8_0, Strix/Zen5, net11 + Core_Root, 32 threads, median of 9)

The microkernel speedup translates to the model level. Prefill of a synthetic sequence, three reductions on
identical input in one process:

Prefill	inner-product (default)	integer outer-product	bf16 outer-product
pp256	978 ms (262 tok/s)	1152 ms — 0.85×	531 ms — 1.84×
pp512	2167 ms (236 tok/s)	2561 ms — 0.85×	1115 ms — 1.94×

bf16 outer-product is ~1.9× faster end-to-end than the production inner-product default — close to the 2.3×
microkernel figure, so matmul dominates prefill with little dilution from attention/RoPE/RMSNorm. The clean
arithmetic-only comparison (same outer-product structure both ways) integer-outer→bf16 = 1152→531 ms = 2.17×,
matching the microkernel result exactly.

Important — the integer outer-product is not a speed win on its own. It is ~15% slower than the
well-optimized inner-product path on this runtime, with no quality benefit (perplexity bit-identical). Its sole
value is as the structural vehicle that enables the bf16 microkernel. So the deliverable is the bf16 path,
full stop — not "ship the integer restructuring first."

Decode is unaffected — so this is a prefill speedup (read this before quoting the number)

These operators are gated on n > 1; single-token decode routes to the inner-product GEMV and never touches
the outer-product / bf16 kernel. Measured (256-token context, median of 32 decode steps), all three configs are
identical and the bf16 tile counter stays at 0:

Decode (1 tok/step)	tok/s	speedup
inner-product	37.0	1.000×
integer outer-product	37.5	1.015×
bf16 outer-product	37.1	1.003×

So real generation speed is a blend: 1.9× on the prompt (prefill) and 1.0× on the completion (decode),
weighted by your prompt:completion ratio. Prefill-heavy workloads (RAG, classification, long-prompt/short-output)
capture most of the win; long-generation workloads see little. Aside: decode here is ~27 ms/token ≈ 40 GB/s
effective for the 1.1 GB model — well under Strix's LPDDR5X peak, so decode looks kernel-bound rather than
bandwidth-saturated; a future full-width AVX-512 / VNNI decode GEMV may have headroom (separate work).

BF16 accuracy on Llama-3.2-1B (same model the speed was measured on)

Longer-corpus A/B/C (373-token passage — larger than a one-sentence sample, not a standard benchmark corpus;
relative deltas on identical tokens are what matter):

Prefill path	Perplexity	vs inner baseline
inner-product (default)	14.8216	—
integer outer-product	14.8216	+0.00% (bit-identical)
bf16 outer-product	14.8653	+0.30%

The integer outer-product is exactly quality-neutral; bf16 costs +0.30% perplexity. (A 32-token sample
read −0.45%, i.e. noise — the longer passage averages that out to the true small positive cost.) Logits agree to
scaleNormDiff 1.77e-2 even at down_proj's K=8192. So bf16's cost is ~0.3% on Llama-1B (≤ +1.6% on SmolLM-135M).

Caveat / next step

These are still single passages on small models. The prefill trade is well-substantiated — ~1.9× prefill for
~0.3% perplexity on Llama-1B — but a standard corpus (e.g. wikitext-2) and a larger model are the gate before
flipping bf16 on by default. bf16 is the deliverable; the integer outer-product is only its structural vehicle,
and the win is on prefill (decode is unchanged).