{"slug": "rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max", "title": "Rigel: Reverse-Engineering the Metal 4.1 Tensor Compute Path on the Apple M4 Max GPU", "summary": "Researchers at an undisclosed institution reverse-engineered Apple's Metal 4.1 tensor compute path on the M4 Max GPU, revealing that the fp8 matmul2d operation is emulated rather than hardware-accelerated. The study, published as a preprint on arXiv, found the operation sustains only 0.94x the throughput of fp16 despite reading half the operand bytes, indicating it functions as a memory-footprint feature rather than a performance one. The findings, which also showed the operation executes entirely on GPU shader cores with no dedicated matrix datapath, enabled researchers to build a hand-fused GEMM kernel that outperformed the decomposed path by 6.5-12.9% in cache-resident regimes.", "body_md": "arXiv:2606.12765v1 Announce Type: new\nAbstract: Apple's Metal 4.1 exposes a tensor compute path: the Metal Performance Primitives (MPP) matmul2d operation over cooperative_tensor fragments, whose interface is documented but whose hardware behavior is deliberately hidden. The specification states which data-type rows are supported, never whether they are hardware-accelerated, where the operation physically executes, what its accumulator width is, or how it partitions matrix fragments across threads. We present Rigel, an empirical characterization of this path on a single Apple M4 Max (a pre-neural-accelerator generation). Using a checksum-gated, provenance-tracked microbenchmark harness, Rigel recovers eleven facts the v4.1 specification hides or contradicts. The headline finding: the Metal 4.1 fp8 (E4M3) matmul2d is emulated, not accelerated: it sustains 0.94x the throughput of fp16 despite reading half the operand bytes, so on M4 it is a memory-footprint feature, not a performance feature. We further show, via a three-signal triangulation (throughput ceiling, comparison against simdgroup_matrix, and per-rail power attribution), that matmul2d executes entirely on the GPU shader cores with no dedicated matrix datapath and no evidence of Apple Neural Engine routing; that it accumulates in >=fp32; and we reconstruct the opaque 8x8 cooperative_tensor fragment layout Apple documents nowhere. Acting on the characterization, a hand-fused GEMM + bias + GELU kernel beats the decomposed path by +6.5-12.9% in the cache-resident regime. All findings are reproducible from committed MIT-licensed code and per-cell CSVs.", "url": "https://wpnews.pro/news/rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max", "canonical_source": "https://arxiv.org/abs/2606.12765", "published_at": "2026-06-12 04:00:00+00:00", "updated_at": "2026-06-12 04:55:46.240106+00:00", "lang": "en", "topics": ["ai-chips", "ai-infrastructure", "machine-learning", "ai-research", "neural-networks"], "entities": ["Apple", "Metal 4.1", "M4 Max", "Rigel", "GPU", "Apple Neural Engine", "GEMM", "GELU"], "alternates": {"html": "https://wpnews.pro/news/rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max", "markdown": "https://wpnews.pro/news/rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max.md", "text": "https://wpnews.pro/news/rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max.txt", "jsonld": "https://wpnews.pro/news/rigel-reverse-engineering-the-metal-4-1-tensor-compute-path-on-the-apple-m4-max.jsonld"}}