Two developers spent a month building a Linux GPU driver for the M4 Mac Mini from scratch, and now they want everyone to look at how they did it. The result runs Chrome, Firefox, and Minecraft on the machine, and the pair published every experiment along the way so anyone can check their work.
The project is called “Building a Linux GPU Driver for the M4 Mac Mini in One Month.” It is the second part of a series, with the first covering a hypervisor built to reverse-engineer macOS. The goal was simple: a fully OpenGL ES 3.0 compliant GPU driver for the M4 Mac Mini and MacBook Neo, a task that normally takes years.
What They Actually Built
Niklas and the developer behind the blog post created a complete driver stack. On the user side, they built a custom shader compiler, a command stream builder, and a working driver that speaks OpenGL ES 3.0. On the kernel side, they reverse-engineered the AGX firmware ABI from scratch, then wrote a full Linux driver for it.
The proof is in the demos. Chrome and Firefox run WebGL on the M4 Mac Mini with working compositing. Minecraft runs at 200 frames per second. Neither of those things should work on a Linux box without a driver, and both of them do now.
The pair also documented their work in two repositories under Deliverables, where they posted all of their experiments. The point is transparency: anyone who wants to check the provenance of their work can follow the steps themselves.
How They Got There
The project started with a hypervisor that let the team watch what macOS does when it talks to the GPU. From there, the approach was simple: watch the OS, replay its actions, then try to do the same thing from scratch.
The LLM tool, Codex, helped with the replay work. It captured the entire GPU memory state when a firmware “kick” happened, then copied that state back into host memory after a reboot. The tool then tried to rebuild the objects in code, following pointers and making sense of the contents. Over time, Codex reduced the amount of replayed state until everything was built from source.
The developer noticed that Codex had good taste about when to poke the hardware and when to run the hypervisor and capture the state itself. That observation became a key part of the workflow.
The Firmware ABI Problem
The hardest part of the project was the firmware ABI. Apple’s GPU firmware runs a custom RTOS called RTKit, and the kernel driver communicates with it through shared memory. That means the ABI is split across two worlds: the firmware’s own memory and the host’s memory.
Many of the shared structs have firmware-owned fields that the driver must never modify. Those fields have to be learned through reverse engineering. The ABI is complicated enough that the developer compared it to the M1/M2 kernel driver work done by Asahi Lina, calling it “amazing.”
But the A18 Pro firmware ABI is even harder. It has more structs than the M1, more pointers, and a more complicated process for submitting work. The developer noted the complexity in a blunt aside: “What the F@!#, Apple.”
The developer had some documentation on the firmware ABI, but it was highly incomplete and not very useful. The approach remained the same: watch what macOS does, replay it, then build it from scratch.
The Three Big Issues
The developer identified three major problems during the project, and all of them came down to one thing: getting a clean capture of host work.
- Render work submitted after the GPU firmware started would be ACKed and retired without actually doing anything.
- Render work submitted before the firmware started would be ACKed and retired without actually doing anything.
- Work submitted during the firmware startup sequence would be ACKed and retired without actually doing anything.
In every case, the problem was the same: the driver could send commands, but the GPU would not execute them. The solution, in each case, was to figure out what the firmware was expecting and provide it.
The Clean Room Approach
The pair treated Apple’s blobs as opaque objects throughout the project. A friend wrote documentation on these blobs, which the team used to build a clean-room implementation. Most of the user-space work was done by blindly trying things until they worked.
The kernel driver, by contrast, was built from the ground up using only hardware traces from the hypervisor and shaders built by the team. There was no peeking at Apple’s binaries.
That distinction matters. User-space graphics reverse engineering is hard because the blobs are closed, but the kernel ABI is public in spirit if not in name. The team’s approach was to keep the two sides separate: user space stays clean, kernel space stays documented.
What Comes Next
The driver is not ready for end users yet. But the pair is looking to get it to them as soon as possible.
The work is also not finished. The plan includes Vulkan support beyond OpenGL. The team has published all of their experiments, and the repositories remain available for anyone who wants to check the provenance of their work.
The pair’s approach is worth noting. They did not hide their failures or their dead ends. They published everything, including the experiments that did not work. That kind of transparency is rare in this field.
Why This Matters
A GPU driver for Linux on Apple Silicon is a big deal. It means the open-source world can talk to these chips without relying on Apple’s binaries. It means the hardware is not locked behind undocumented blobs.
The fact that it took a month is the real surprise. A month is a massive improvement over years, and the team admits that days was too optimistic. But weeks is still a huge win.
The project also shows what modern reverse engineering looks like. It is not a dark art done in secret. It is a transparent, documented process that anyone can follow. The pair’s use of the hypervisor and Codex is a practical example of how machine learning can help with low-level systems work.
The work is impressive. The transparency is admirable. And the fact that Minecraft runs at 200 fps on a Linux box is just the cherry on top.
Anyone who has ever wanted to run a game on a non-standard platform knows the feeling. The pair just made it happen, and they brought the whole notebook along for the ride.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.