What a Linux GPU driver for the M4 Mac Mini gives you today

A working graphics driver on Apple silicon under Linux is the prerequisite for GPU compute, not the delivery of it. The post says the team is looking to get the driver to end users as soon as possible, without giving a date. Anyone sizing an M4 Mac Mini for local inference under Linux should read the current state as a kernel and user-space foundation.

Building a GPU driver normally takes years. The stated goal was days, which the post calls overly optimistic, and the work landed in weeks. On Apple silicon the kernel driver does not interface directly with the hardware; it talks to GPU firmware running a custom RTOS called RTKit, so the first step was figuring out the firmware ABI rather than getting hardware access.

The ABI is the reason this was hard. Per the post, Apple took a regular kernel driver, cut it in half, put half of it in the AGX and had the two halves communicate through shared structs in memory, many of which interleave firmware-owned fields that must never be modified with host-controlled fields. The A18 Pro version has 1.5x as many structs as the M1 ABI that Asahi Lina reverse engineered over grueling 12-hour days, twice as many pointers, and a significantly more complicated process for submitting work.

The AGX broadly supports two kinds of work, compute and render. In the regular GUI path, compute work is only scheduled after a significant amount of render work has already executed, which made a clean compute capture hard to obtain. The capture Codex eventually got was 336 MB and impossible to replay; Codex also spent over a week trying to construct the objects directly from that capture and was ultimately unsuccessful.

The fix came from a different Codex session and is a reusable pattern for trace-based reverse engineering: boot into single-user mode so no render work is done, install a LaunchDaemon that runs at the moment Metal becomes available, run a tiny supplied Metal program, then capture and replay that pure compute trace. Codex deconstructed the resulting trace within a few hours and had compute working within a few days. The post says the smallest possible capture, run in single-user mode so as not to perturb results, should have been the strategy from the start.

The post says Codex has no idea why the original compute codebase did not work, and that the working and broken versions look very similar. The other finicky area was partial renders, which occur when the Tiled Vertex Buffer is not large enough to store the current geometry and the driver must either increase the buffer size or render part of the geometry, reload the buffer with the rest, and finish. The post describes this as essentially adding save and resume to a GPU driver, and as one of the hardest things to figure out.

On the kernel side, moving from a Python prototype driver to a fully featured Linux driver took three days, one of which was almost totally wasted because Codex chose to tackle partial renders, by far the hardest task, before compute, the easiest. The sequence was: rewrite the existing drm-shim in Rust following the same pattern to get a synchronous Rust driver, make the frontend asynchronous, refactor GPU submissions to be asynchronous and listen for firmware events with work associated to a fence, then add low-hanging optimizations such as batched work submission.

The A18 Pro user space is very different from the M1/M2: new descriptor formats, a new ISA, and a tile based deferred renderer designed to run Metal. In the first phase, Claude worked from Metal programs to build a disassembler and assembler and to enumerate descriptors and command streams, including features Linux cannot use such as tessellation. Closing the gap from disassembling and reassembling programs to compiling arbitrary programs is where the post says Claude did a horrible job and made basically zero progress.

The second phase split into two approaches after Niklas finished his drm-shim for the M4 Mac Mini. Cody Ho prioritized hardware reverse engineering, spending most of his agent's time on hardware experiments with the intent to write a spec and have the LLM implement it; Niklas built Mesa first and did reverse engineering only to unblock functionality. The post says Niklas made significantly faster progress, because his agent was grounded by the need to actually build Mesa, while the hardware-first agent spent a lot of time on minor, inconsequential tasks in the name of completeness. During reverse engineering the team also found behavior supported by the hardware but not supported by Metal, by directly manipulating the bits of instructions.

OpenGL ES 3.0 conformance is a graphics claim. The post states the goal was conformant OpenGL and soon Vulkan, but does not report Vulkan working, does not mention OpenCL or any other compute API, and describes no path from kernel-level compute submission to a framework an inference stack could target. Metal, named in the post as Apple's proprietary graphics framework, was the probe target for reverse engineering, not something reimplemented for Linux.

There are also no inference-relevant numbers. The only performance figure in the piece is Minecraft at 200fps. The post is silent on memory bandwidth, unified memory allocation limits, sustained compute throughput, power draw and thermals, and does not mention any inference runtime. A claim that this makes the M4 Mac Mini a Linux inference box today is not supported by the source.

The loudest objection in the Hacker News thread is provenance. One commenter points out that Asahi Linux, described there as the biggest project for Linux on Apple silicon, has a strictly no-AI policy, so this LLM-assisted work cannot be upstreamed there, and predicts AI-assisted forks will dominate because most people just care about getting stuff working. Another replies that Asahi does not have a monopoly over Linux for Apple Silicon and that upstream Linux does not ban LLMs. A third argues the hard part was always reversing the black box, and that they or others can now write a driver from those discoveries.

One commenter raised a sharper process complaint: clean room is not 100% legally necessary for reverse engineering, but they would not use an LLM for RE work when the models may have been trained on the thing being reimplemented, and not mentioning LLMs until after showing a page of LLM-derived firmware ABI is a trap for anyone trying to be clean room. The post's own answer is that no Apple binaries were looked at, only hardware traces from the hypervisor and shaders the team wrote themselves; required Apple blobs were treated as opaque objects with documentation written by a friend; and all experiments were published in the twin agx-re repos so anyone can verify provenance.

Other commenters questioned whether upstream projects should accept code from an ex-Apple employee while, as they describe it, Apple is suing OpenAI over trade secrets. One commenter replying in the thread says they never saw any macOS source code during their time at Apple, had not even heard of components like SPTM, have not worked there since June 2025, and draws the WINE comparison: that project bans anyone who has looked at the Windows source, not all former Microsoft employees. Another notes that important kernel components such as ZFS have long lived out of tree, and frames the risk here as a cease-and-desist or NDA question rather than a licensing or code-quality one.

A separate concern in the same discussion is durability. One commenter argues that today's models produce disposable software that works for a while, ages quickly and needs to be thrown away, unless someone who knows what they are doing guides the output. For a kernel driver that sits under every process on the machine, that is a structural question rather than a stylistic one. The post's counterweight is the kernel-side sequence above, which it calls pretty routine engineering work that LLMs are definitely capable of, plus the note that Codex used the hypervisor to debug its own code by capturing the full address space and comparing it to known good samples.

Three things would change the picture for compute users. Vulkan is stated as a goal alongside OpenGL with no timeline. An end-user release is promised as soon as possible with no date. The M5 user space is described only as mostly reverse engineered. Until there is a compute API on top of the working submission path and a published throughput number, the useful summary is that the AGX firmware ABI has been reverse engineered from scratch and the experiments published in the twin agx-re repos, and that the inference stack on top of it does not exist yet.