When the RISC-V matrix extensions effort was restructured into four complementary approaches at Summit Europe 2025 in Paris, it was a bold architectural bet — that the breadth of the RISC-V ecosystem demands not one rigid solution but a family of extensions spanning from lightweight vector-matrix primitives to fully independent matrix engines. One year later, that bet is paying off. This talk reports on the rapid progress across the matrix extension family as two of the four extensions — the Integrated Matrix Extensions (IME) and the Vector Matrix Extensions (VME) — converge on specification freeze. We trace the architectural decisions that brought IME and VME from concept to maturity: algebraic tile geometry that scales naturally with VLEN, the deliberate reuse of RVV state for seamless software integration, and the introduction of dedicated accumulator registers to unlock higher computational intensity where implementations demand it. Crucially, work is starting to unify IME and VME through a common LLVM-MLIR lowering path — giving compilers and AI/ML frameworks a single abstraction that targets both extensions, ensuring that the software ecosystem scales with the hardware rather than fragmenting across it. For Europe's semiconductor industry — from research institutions and startups to established design houses — standardized, open matrix extensions represent a strategic opportunity: competitive AI/ML and HPC capability on an open ISA, free from proprietary lock-in. RISC-V matrix support is no longer a roadmap item. It is arriving.

RISC-V's Zvvm matrix extension stores all tile state in the standard V register file and derives tile geometry algebraically from VLEN, SEW, and a new aspect-ratio field λ. This yields arithmetic intensity that scales with VLEN: a binary compiled at VLEN=256 delivers higher throughput at VLEN=65536 with no recompilation. The same partial-VL mechanism that enables one-column-at-a-time embedded streaming also drives full HPC bulk tiling, while microscaling is integrated via vm-bit opcode aliasing with no new architectural state.

Tile dimensions are not programmer-specified constants — they are consequences of existing parameters. The tile is always square: M = N = VLEN/(SEW×λ), with inner dimension K_eff = λ×W×LMUL. Arithmetic intensity (M/2) grows proportionally with VLEN, and the ratio of intensity to cache-to-VRF bandwidth remains constant — a provable algebraic identity with no equivalent in Arm SME or Intel AMX.

Zvvm's geometry knobs form an intent vocabulary expressed from both sides: software selects LMUL and VL to control K_eff depth and streaming granularity; hardware determines λ and VLEN to shape the tile for its datapath. Setting VL = K_eff with LMUL = 1 gives portable streaming; increasing LMUL or computing multiple C panels trades register pressure for compute intensity — all via the same opcode.

Microscaling (MX) support is integrated by aliasing the vm bit in FP multiply-accumulate opcodes, introducing no new encoding space, registers, or modes.