兩名開發者用約一個月為 M4 Mac mini 開發 Linux GPU 驅動程式，多數程式碼由編碼智能體撰寫

Apple Silicon is powerful hardware, but Linux support on it has always been a community-driven uphill battle. In September 2026 two developers, Cody Ho and Niklas Sheth, published a working, OpenGL ES 3.0 conformant Linux GPU driver for the M4 Mac mini and the MacBook Neo, built in about a month. Two facts frame how to read it, and both are missing from most coverage. First, the bulk of the code was written by LLM coding agents: Ho used Codex for the kernel and firmware reverse engineering and Claude for the user-space work, and he describes the result as "likely the first ever fully LLM-written GPU driver." Second, it ships in Gravity Linux, a Fedora remix that was forked from Asahi Linux over precisely that question. Asahi's contribution policy forbids generative AI; Gravity's permits it under disclosure and provenance rules. Neither of those facts settles whether the work is good, but you cannot read the project accurately without them.

💡 Why This Matters

Most people running Linux on Apple Silicon hardware are doing it through Asahi Linux, which has made incredible progress on M1 and M2 chips. The M4 generation is newer territory. Getting GPU acceleration working on Linux means the difference between a usable desktop and a machine that renders everything in software, burning CPU cycles on tasks the GPU should be handling.

Beyond the Apple Silicon story, this project is a case study in something narrower: what coding agents do when pointed at a hard reverse engineering problem that already has an exhaustive test suite attached. The authors credit that suite directly, writing 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.

🏗️ The Core Strategy: Clean-Room RE, Driven by Agents

It is tempting to assume the M4 driver is the Asahi driver patched for a newer chip. It is not. The write-up is titled "Building a GPU Driver From Scratch in One Month", and the team reports reverse engineering the AGX firmware ABI and the M4 user space themselves from live hardware traces, without looking at Apple binaries. They did reuse Asahi's kernel UAPI unchanged, and they credit the M1 and M2 driver for having already settled many of the design questions, but the code is new, including a custom shader compiler and command stream builder. They also report that the A18 Pro firmware ABI has roughly 1.5 times as many structs and twice as many pointers as the M1 and M2 one, so it was not a matter of adjusting register offsets.

The other half of the method is the part the usual framing leaves out. The reverse engineering and most of the implementation ran as long, largely unattended agent loops. On the kernel side, Ho describes the agent capturing full GPU memory state through a hypervisor he had written for an earlier project, replaying that state after a reboot, and then progressively reconstructing 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.

What that cost in human judgement is documented too, and is more useful than the headline. Ho reports that one compute capture came back at 336 MB and was impossible to replay, that the agent spent over a week on it without success, and that the fix 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.

🧰 The Toolchain

Reverse engineering a GPU driver without documentation means you need good instrumentation. The general toolchain for this kind of work includes:

A purpose-built hypervisor: Ho had already written a hypervisor to run and observe macOS on the hardware. That is what produced the firmware ABI traces, and the agents drove it directly, capturing full address spaces and diffing them against known-good samples when their own code misbehaved
Self-written Metal programs, not Apple's tooling: the reference workloads were small Metal shaders the team wrote themselves, compiled and run so they could 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
The Khronos conformance test suite: an existing, exhaustive corpus the driver has to pass. This is what the authors credit for keeping agent-written code grounded
Mesa and DRM: The userspace side of the driver lives in Mesa; the kernel side lives in the Linux DRM subsystem. Both have to agree on the ABI for rendering to work end to end

All of the reverse engineering experiments have been published so that the provenance of the work can be checked independently, which is the point of a clean-room process rather than an extra. On upstreaming, 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, and that they expect their code "will be held to a higher standard than human-written code." The kernel driver is further off, because they intend to wait for the M1 and M2 driver to go upstream first.

🔧 How GPU Drivers Actually Fit Together on Linux

If you have not dug into this before, here is the rough stack. 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 OpenGL or Vulkan API implementation. They communicate through ioctls defined by the DRM subsystem.

For Apple Silicon, there is an additional layer. The GPU firmware runs on a separate processor inside the chip and has its own command protocol. The kernel driver does not program the GPU registers directly the way a traditional PC GPU driver might. Instead it constructs command buffers and submits them to the firmware, which then drives the hardware. Reverse engineering that firmware protocol is where most of the hard work lives.

A simplified view of the stack looks like this:

Application (game, desktop compositor, etc.)
    |
Mesa (OpenGL / Vulkan userspace driver)
    |
DRM ioctl interface (kernel boundary)
    |
Kernel DRM driver (memory, scheduling, command submission)
    |
GPU firmware (Apple proprietary, runs on embedded processor)
    |
M4 GPU hardware

Every layer has to be correct for rendering to work. A bug at any level shows up as a crash, a black screen, or corrupted output.

🛡️ Security and Stability Considerations

Running out-of-tree kernel modules on production hardware carries real risk. A buggy GPU driver can cause kernel panics, memory corruption, or silent data errors. If you are experimenting with early driver work on Apple Silicon Linux, keep these things in mind:

Keep your GPU driver experiments on a dedicated machine or a VM, not on anything you rely on day to day
Use kernel lockdown and secure boot awareness appropriate to your threat model. Early driver code often requires disabling module signing, which opens up other attack surfaces
Snapshot your disk before major driver updates. Tools like timeshift or a simple dd image of your root partition will save you a painful recovery
Watch kernel logs closely with dmesg -w when testing new driver builds so you catch soft errors before they become hard crashes

🚀 What a One-Month Timeline Actually Looks Like

"Functional" here means more than a usable desktop. The claimed result is full OpenGL ES 3.0 conformance, with the failing tests being optional extensions, plus OpenGL 3.3 in the shipped Gravity Linux alpha, WebGL working in Chrome and Firefox with compositing, and Minecraft at 200fps. Vulkan 1.4, OpenGL 4.6, OpenGL ES 3.2, OpenCL, Direct3D 12 via Proton and ray tracing are all listed as remaining work rather than as done.

What made a month possible is a specific combination, and the authors are explicit about each part: a hypervisor that already existed for capture, a conformance suite that already existed to grade against, the M1 and M2 driver as a map of which design decisions tend to be correct, and coding agents doing the repetitive reverse engineering and implementation. It was not uniformly fast. One compute capture consumed more than a week and was abandoned, and the productive approach was only found afterwards.

For scale, the M1 and M2 Asahi GPU driver took years and many contributors, and the Gravity authors credit that work in plain terms. The two efforts are now separate projects: Asahi Linux continues on its own terms and its own policies, and Gravity Linux is the Fedora remix where this M4 driver ships.

🔬 Applying This to Your Homelab

Even if you are not writing kernel drivers, there are practical takeaways here for anyone running ARM hardware in a homelab.

First, if you are running Linux in a VM or container on an M-series Mac, check whether your virtualization stack exposes GPU acceleration to guests. Tools like QEMU with VirtIO GPU, or commercial options, vary significantly in how much of the host GPU they surface. Knowing the driver stack helps you understand what you are actually getting.

Second, the habit of iterating inside a snapshotted VM is worth adopting generally, even though it is not what this project did. Its iteration ran against real hardware, observed through a hypervisor written for the purpose. Still, if you are developing anything that touches kernel APIs or low-level hardware, do your iteration inside a VM with snapshots. The time you spend setting that up is paid back the first time a bad config would have bricked a bare-metal node.

Third, be clear about which project covers which hardware, because the two are easy to conflate. Asahi Linux is the long-running effort and is where M1 and M2 support lives. The M4 driver described here is Gravity Linux's, and its first release is an early alpha for the M4 Mac mini published on 18 September 2026, which the authors label "FOR DEVELOPERS" and say is "not yet ready to be used as a daily driver." Suspend, display output over the USB-C ports and Thunderbolt or USB4 do not work in it, HDMI does, and the authors warn there may be no upgrade path from the alpha to the beta. Neither project's Apple Silicon GPU driver is upstream in the kernel yet. Check both projects' blogs and the upstream kernel lists before committing hardware to a production workload.

✅ Wrap Up

A conformant Linux GPU driver for the M4 Mac mini in about a month is a notable result, and the method behind it is specific: clean-room reverse engineering from hypervisor traces, an existing conformance suite as the grader, and coding agents writing most of the code. The code is not ready for general use, it is not upstream, and it ships for now in Gravity Linux rather than Asahi Linux, for policy reasons rather than technical ones. If you want the detail first hand, the write-up is at codyho.dev and the driver repositories are linked from it. The two projects' positions on generative AI in contributions are set out in full at Gravity's LLM Use and Clean-Room Policy and Asahi's Generative AI Policy, and both are short enough to read before forming a view.

Related from the lab

Originally published at codewithromi.com.