OCP-FP8 (E4M3/E5M2) vs MXFP8 precision differences on CDNA3 and CDNA4

OCP-FP8 (Open Compute Project FP8) defines two formats: E4M3 (4 exponent bits, 3 mantissa bits - higher precision, smaller range) and E5M2 (5 exponent bits, 2 mantissa bits - lower precision, larger range). These are per-tensor or per-channel scaled formats. MXFP8 (Microscaling FP8) is part of the OCP MX specification and uses block-scaled representation where each block of elements shares a scaling factor. On CDNA3 (MI300X/MI325X), only OCP-FP8 is supported. On CDNA4 (MI350X/MI355X), both OCP-FP8 and MXFP8 are natively supported. AMD's product pages print them separately: 'Peak OCP-FP8 Performance (E5M2, E4M3)' and 'Peak MXFP8 Performance'. On MI355X, both are 5.0 PFLOPs dense. The key difference is that MXFP8's block scaling provides better numerical accuracy for inference workloads with large dynamic ranges, while OCP-FP8 is simpler and has broader ecosystem support. AMD's vLLM blog notes that FP8 KV cache on MI300X uses E4M3 format. RESOLVED (2026-10-04 cross-reference repair): the bare part names in affected_by_hardware were expanded to their record ids - mi300x -> amd-instinct-mi300x, mi325x -> amd-instinct-mi325x, mi350x -> amd-instinct-mi350x, mi355x -> amd-instinct-mi355x. Each name matched exactly one accelerator record in data/accelerators/, so no variant was chosen between siblings (MI300X and MI325X are both CDNA3, MI350X/MI355X/MI350P all CDNA4) - the id is forced by the part name. This field is still a mixed bucket: it also carries the architecture codename values gfx942/gfx950, which are not ids and were left alone.