Apple Locked Down the Boot Chain. He Built an M4 Linux GPU Driver in 30 Days.

Apple Locked Down the Boot Chain. He Built an M4 Linux GPU Driver in 30 Days.

LinuxApple SiliconGPUAI

Sources:codyho.dev

Hitting 212 FPS on the M4

How long does it take to get Minecraft running at 212fps on an M4 Mac Mini, or to make WebGL render smoothly in a browser? Writing Linux drivers for Apple Silicon used to be an exhausting marathon—the M1-era kernel driver was brute-forced by Asahi Lina working 12 hours a day. Now, developers Cody Ho and Niklas have compressed this multi-year engineering feat into a single month, standing up an OpenGL ES 3.0 compatible GPU driver from scratch.

There are no trade secrets leaked here. They employed clean-room reverse engineering, examining zero Apple binaries, relying solely on their own shaders and hardware execution traces. In a black-box ecosystem, as long as you can intercept the real execution signals, the community can build an alternative.

WebGL running on Chrome and Firefox with this driver Figure: Chrome and Firefox rendering normally on this driver. Source: codyho.dev

Apple Split the Driver in Half

The biggest roadblock to writing drivers on modern Apple Silicon is Apple’s proprietary firmware ABI (Application Binary Interface). Traditional kernel drivers talk directly to the hardware, but Apple’s approach slices the driver in two: one half is embedded as firmware inside a custom operating system called RTKit, while the other half communicates with the host via data structures in shared memory.

In the M4 and A18 Pro chips, this communication mechanism is even more convoluted than in the M1 era. Data structures have increased by 1.5 times, pointers have doubled, and the workflow for submitting rendering jobs is like a maze. Firmware-owned fields and host-controlled fields are heavily intertwined, making it incredibly difficult to untangle.

The Dumb Approach Beat Reading Documentation

How do you unravel this mechanism? Cody Ho brought out a custom-built hypervisor to precisely record the real hardware behavior of macOS. Then, a Large Language Model Agent was put on the assembly line to perform blind trials.

The Agent’s operation was straightforward: wait for the first firmware-visible event to appear, and save the entire GPU memory state. After rebooting, copy the exact state back into the host memory, trigger execution, and stare intently at the memory changes in the output pages.

If it failed, adjust the pointers and fields, and run it again. As the experiments progressed, the number of memory pages requiring hard copies decreased, until everything could be constructed from scratch using code. GPU driver development shifted from brain-burning logical deduction to a high-frequency trial-and-error loop.

Minecraft hitting 212fps on an M4 Mac Mini Figure: Minecraft hitting 212fps on an M4 Mac Mini. Source: codyho.dev

Clean Data Trumps Compute Power

However, this trial-and-error approach hit a wall in the Compute module. Under a graphical interface, compute jobs are always queued behind a massive amount of rendering tasks, resulting in recorded execution traces as large as 336MB, filled entirely with irrelevant noise. The Agent spent over a week trying to construct objects on its own, with zero progress.

The solution came down to engineering intuition: Cody Ho turned off the graphical interface, booted into single-user mode, and ran a tiny program the moment the graphics interface became available. This captured a minimal, pure-compute execution trace. This clean data was parsed in a matter of hours, and the compute module was successfully running within days. Feeding an Agent 300MB of dirty data is far worse than spending a few hours building a scaffold that outputs deterministic results.

The Lockdown Became an Accelerator

Apple tightened the boot chain, forcing the open-source community to build custom drivers to run Linux on Macs. This seemingly hardest path, aided by record-and-replay mechanisms and automated tools, ironically turned into a shortcut.

Compressing years of team-level development into a month wasn’t because the model suddenly achieved a low-level epiphany. It was because the developers used a hypervisor to turn a complex system black box into an experimental playground that could be reset infinitely with immediate results. The path of reading closed firmware documentation was blocked, but the path of blind trials through ultra-fast feedback loops was wide open.

References:

  • Cody Ho: Building a GPU Driver from Scratch in One Month
  • Asahi Linux Project (M1/M2 kernel driver background)