The M4 Mac mini Linux GPU Driver Was Mostly Written by AI

Two developers shipped an OpenGL ES 3.0 conformant Linux GPU driver for the M4 Mac mini in about a month. Coding agents wrote most of it. Cody Ho and Niklas Sheth published the driver in September 2026, covering the M4 Mac mini and the MacBook Neo. Ho describes the result as "likely the first ever fully LLM-written GPU driver."

That headline is the least useful part. The documented record of where the agents stalled, and what a human had to decide, is the part worth reading.

What shipped, and where

The driver ships in Gravity Linux, a Fedora remix forked from Asahi Linux over exactly this question. Asahi's contribution policy forbids generative AI. Gravity's permits it under disclosure and provenance rules. The split matters for anyone deciding which distribution to run on Apple Silicon: the two projects now differ on code provenance, not just on hardware support.

Most people running Linux on Apple Silicon are on Asahi, which has made deep progress on M1 and M2. The M4 generation is newer ground. GPU acceleration there is the difference between a usable desktop and a machine rendering everything in software on the CPU.

It is not the Asahi driver with new offsets

The obvious assumption is that the M4 driver is the M1 driver patched for a newer chip. The team says it is not. They reverse engineered the AGX firmware ABI and the M4 user space themselves from live hardware traces, without looking at Apple binaries. They reused Asahi's kernel UAPI unchanged and credit the M1 and M2 driver for settling many design questions, but the code is new — including a custom shader compiler and command stream builder.

The scale of the gap is documented. The team reports that the A18 Pro firmware ABI has roughly 1.5 times as many structs and twice as many pointers as the M1 and M2 ABI. Register offsets were never going to cover that.

How the agents were actually driven

Ho used Codex for the kernel and firmware reverse engineering. Sheth used Claude for the user-space work. Both ran as long, largely unattended agent loops rather than as chat sessions.

On the kernel side, the agent captured full GPU memory state through a hypervisor Ho had written for an earlier project, replayed that state after a reboot, and progressively reconstructed the firmware structures in code until nothing was being replayed any more. On the user-space side, Sheth's agent iterated Mesa against the Khronos conformance suite until the OpenGL ES 3.0 tests passed.

The authors are explicit that the test suite did the heavy lifting. They write that "the hardest and most sensitive part of working with LLMs, giving them good tests to ground them, is already done for us" by the Khronos conformance tests. That is the transferable lesson: this was not a problem the agents solved by being clever. It was a problem with an exhaustive, pre-existing oracle attached.

Where the agents failed

The failure log is specific, and it is the most useful thing in the write-up.

Ho reports that one compute capture came back at 336 MB and was impossible to replay. The agent spent over a week on it without success. The fix was not a better prompt — it was a human decision about method: boot into single-user mode so no render work runs, trigger a minimal Metal compute program, and capture that instead. He also reports a day lost because the agent chose the hardest subtask first.

Neither developer claims the agents worked without supervision. Read against the "first fully LLM-written driver" framing, that is the correction: the agents produced the volume, and a human made the calls about what to capture and in what order.

The clean-room claim, and how to check it

Provenance is the part most likely to be litigated, so the team built for it. They report writing their own small Metal shaders as reference workloads rather than using Apple's tooling, compiling and running them to observe what changed in memory. They report not looking at Apple binaries, treating required Apple blobs as opaque objects, and having a third party document those blobs so the implementation could be written clean-room.

All of the reverse engineering experiments have been published so the provenance of the work can be checked independently. For a project whose output is both agent-written and clean-room, that publication is load-bearing rather than a nicety.

How the pieces fit

For readers who have not dug into Linux graphics: the kernel side handles memory management, command submission, power management, and scheduling. The userspace side — Mesa, for open-source drivers — handles shader compilation, draw call translation, and the OpenGL or Vulkan API implementation. They communicate through ioctls defined by the DRM subsystem.

Apple Silicon adds a layer. The GPU firmware runs on a separate processor inside the chip with its own command protocol. The kernel driver does not program GPU registers directly the way a PC GPU driver might; it builds command buffers and submits them to the firmware, which drives the hardware. Reverse engineering that firmware protocol is where most of the work lives, and it is why the struct-and-pointer count above translates into months of effort rather than an afternoon.

What to watch next

Upstreaming is the open question, and the two halves are on different timelines. The authors say the Mesa side uses the unmodified Asahi UAPI, so there are no policy obstacles there, but that it still needs more testing and human review. They expect their code "will be held to a higher standard than human-written code." The kernel driver is further off: they intend to wait for the M1 and M2 driver to land upstream first.

Three things to track. Whether Mesa maintainers accept agent-written code at all, and under what disclosure. Whether the published RE experiments survive outside scrutiny of the clean-room claim. And whether the method generalizes — because the honest reading of this project is that it worked where a complete conformance suite already existed, which is not where most driver work happens.