MXFP8 (OCP microscaling FP8, E4M3 + E8M0)

MXFP8 is the 8-bit member of the same OCP microscaling family as MXFP4 - which the enum treats as a separate value, correctly, because the element format (E4M3/E5M2 vs E2M1) and the supported hardware both change. It is directly evidenced as a shipping hardware recipe by the TensorRT-LLM documentation footnote that FP8 blockwise-scaling GEMM kernels on sm100/103/107 use the MXFP8 recipe (E4M3 act/weight with UE8M0 act/weight scale), slightly different from the SM90 FP8 recipe (E4M3 with FP32 act/weight scale) - quant-trtllm-quantization. So on Blackwell, 'blockwise FP8' effectively means MXFP8. The MX family supports any element E/M combination (E2M1, E3M2, E4M3, E5M2 are the common ones) under the shared-scale block scheme. No quality delta recorded. UPGRADE (2026-10-03): MXFP6 is now recorded separately as quantization/mxfp6, and the enum has no mxfp6 value, so that record borrows 'mxfp8' as its nearest neighbour - the enum is missing the middle rung of its own family. The practical consequence, per qlab-micromix-paper: a Blackwell-targeted mixed-precision kernel wants to select MXFP4, MXFP6 or MXFP8 PER CHANNEL, choosing higher precision for channels where MXFP4's error is too large. That per-channel choice is unavailable as a first-class format today and is the main reason to add the enum value. Also worth carrying: the MicroMix paper's stated motivation is that Blackwell's new FP4 Tensor Cores offer up to 4x over FP16 while existing INT4-based kernels cannot exploit them because of data-format mismatch - which is the same w4a16-vs-w4a4 lesson as QuaRot, arriving from the hardware side.