perf(cpu): the R4 Q8_0 prefill kernel has no AVX-512 or VNNI tier

[kkokosa]

Observation

ComputeRowsQ8_0Interleaved (src/DotLLM.Cpu/Kernels/MatMul.cs:324) is the kernel every Q8_0 prefill token goes through after #400 routed prefill to GemmR4TiledQ8_0. Its entire ISA dispatch is:

if (Avx2.IsSupported)  -> VecDotQ8_0Avx2_4RowsR4
else                   -> VecDotQ8_0ScalarR4

There is no AVX-512 tier and no VNNI tier. VecDotQ8_0Avx2_4RowsR4 is Vector256 throughout — Avx2.Sign, vpmaddubsw, vpmaddwd(ones), four separate Vector256<float> accumulators, per row per block.

The VNNI work from #399 went into ComputeRows (MatMul.cs:134), gated on Avx512BW.IsSupported && AvxVnni.IsSupported. That is the row-major path. GemmR4TiledQ8_0 reaches it only for the tailRows remainder (at most 3 rows per matrix).

So on an AVX-512 host the Q8_0 prefill matmul runs entirely on 256-bit AVX2 integer ops. #399 gave VNNI to the decode path; #400 then routed prefill away from it.

Proposed change

Add VecDotQ8_0Vnni_4RowsR4 — port the dual-block structure of ProcessVnniDualBlock / VecDotQ8_0Vnni_4Rows onto the R4-interleaved layout — and give ComputeRowsQ8_0Interleaved the same tiered dispatch ComputeRows already has:

Tier	Guard	Kernel
VNNI	Avx512BW && AvxVnni	VecDotQ8_0Vnni_4RowsR4 (new)
AVX-512	Avx512BW	512-bit R4 variant (new, or fall through to AVX2 initially)
AVX2	Avx2	VecDotQ8_0Avx2_4RowsR4 (existing)
scalar	—	VecDotQ8_0ScalarR4 (existing)

The R4 layout should suit VNNI better than row-major does: the four rows' blocks for a given column are contiguous within 136 bytes, and dual-blocking runs along K. That directly addresses the "blocks aren't contiguous 64 bytes, so the V512 path pays two extra Vector256->Vector512 inserts per cell" problem recorded in #322.

Bit-exactness argument carries over from #399 unchanged: both forms group 4 consecutive byte products into one int32 lane, the i16 intermediate saturates only above 32767, and |x|,|w| <= 127 bounds each lane at 2127127 = 32258.

This may not be a win

#322 comment [4699772011 thread] records the counter-hypothesis directly: "Zen5 executes the 256-bit maddubs+madd pair with more throughput/ILP than one serial 512-bit VPDPBUSD." Four independent 256-bit accumulators is reasonable ILP and going wider can serialize. This is an experiment, not a presumed fix — a negative result is a useful outcome and should be recorded as one.

Measurement plan

1. Parity first — vs VecDotQ8_0ScalarR4 over blockCount in {1, 2, 3, 8, 17, 18, 48, 128} (covers the odd-block tail, the single-block case, and multi-tile K), plus a discrimination self-check: perturb one cell and confirm the test actually fails, so a skipped ISA guard cannot masquerade as a pass.
2. Microbenchmark — new vs existing R4 kernel at K=4096, matching the shape used in perf(cpu/matmul): AVX-512 VNNI for Q8_0 outer-product (AvxVnni.V512 / VPDPBUSD-512) — requires .NET 11 bump #322 so numbers are comparable to that table.
3. GEMM level — GemmR4TiledQ8_0 at realistic prefill shapes (m = hidden dim, n = 256/512), where L2 tiling and thread partitioning show up and the microbenchmark will not.
4. End-to-end — Llama-3.2-1B Q8_0 pp256/pp512 through bench_compare, with llama.cpp as the external anchor. This is the number that decides whether it mattered.

Why this before anything else in the Q8_0 backlog

• Known-positive prior: VNNI already earned its place in the row-major path via perf(cpu): use AVX-VNNI vpdpbusd for the Q8_0 4-row dot product #399.
• Zero external dependency — net10.0, no new intrinsic, no TFM bump, no weight-format change.
• It re-baselines the rest of the backlog. Judging bf16 (perf(cpu/matmul): AVX-512 VNNI for Q8_0 outer-product (AvxVnni.V512 / VPDPBUSD-512) — requires .NET 11 bump #322), a scale-separated layout, or the outer-product restructuring (perf(cpu/matmul): Q8_0 outer-product GEMM via AVX2 VNNI (VPDPBUSD-256) — unblock #61 register pressure #321/perf(cpu/matmul): Q8_0 outer-product GEMM via AVX2 VNNI (VPDPBUSD-256) — unblock #61 register pressure #323) against an AVX2-only integer prefill kernel is not a fair test of any of them.

Acceptance criteria

• VecDotQ8_0Vnni_4RowsR4 matches VecDotQ8_0ScalarR4 across the discriminating block counts above.
• Discrimination self-check confirms the tests fail on a deliberately perturbed cell.
• ComputeRowsQ8_0Interleaved dispatches tiered, with the AVX2 path retained as fallback and still covered by tests.
• Microbenchmark and end-to-end prefill numbers recorded in the PR, whichever direction they point.
• If VNNI is not a win on this hardware, the AVX2 path stays the default and the result is documented rather than shipped.

References

• src/DotLLM.Cpu/Kernels/MatMul.cs — ComputeRowsQ8_0Interleaved (:324), VecDotQ8_0Avx2_4RowsR4 (:235), VecDotQ8_0ScalarR4 (:204), GemmR4TiledQ8_0 (:380), ComputeRows (:130), VecDotQ8_0Vnni_4Rows (:883), ProcessVnniDualBlock (:933)
• perf(cpu): use AVX-VNNI vpdpbusd for the Q8_0 4-row dot product #399 — AVX-VNNI vpdpbusd for the row-major Q8_0 4-row dot product
• perf(cpu): route Q8_0 prefill through an L2-tiled R4 GEMM #400 — routed Q8_0 prefill through the L2-tiled R4 GEMM
• perf(cpu/matmul): AVX-512 VNNI for Q8_0 outer-product (AvxVnni.V512 / VPDPBUSD-512) — requires .NET 11 bump #322 — AVX-512 VNNI / BF16 investigation by @jamesburton; the ILP counter-hypothesis and the scale-separated-layout follow-up both come from that thread