Zwei Entwickler haben einen Monat damit verbracht, einen Linux-GPU-Treiber für den M4 Mac Mini von Grund auf neu zu erstellen, und möchten nun, dass jeder nachverfolgt, wie sie es gemacht haben. Das Ergebnis lässt Chrome, Firefox und Minecraft auf der Maschine laufen, und das Duo veröffentlichte alle Experimente entlang des Weges, damit jeder ihre Arbeit überprüfen kann.
Das Projekt trägt den Namen „Building a Linux GPU Driver for the M4 Mac Mini in One Month“. Es ist der zweite Teil einer Reihe, wobei der erste eine Hypervisor behandelt, der entwickelt wurde, um macOS rückwärts zu entwickeln. Das Ziel war einfach: ein vollständig OpenGL ES 3.0-konformer GPU-Treiber für den M4 Mac Mini und das MacBook Neo, eine Aufgabe, die normalerweise Jahre dauert.
Was Sie Tatsächlich Gebaut Haben
Niklas und der Autor des Blog-Posts haben einen kompletten Treiber-Stack erstellt. Auf der Benutzerebene haben sie einen benutzerdefinierten Shader-Compiler, einen Befehlsstrom-Builder und einen funktionierenden Treiber erstellt, der OpenGL ES 3.0 spricht. Auf der Kernel-Seite haben sie das AGX-Firmware-ABI von Grund auf neu rückentwickelt und anschließend einen vollständigen Linux-Treiber dafür geschrieben.
Der Beweis liegt in den Demos. Chrome und Firefox laufen WebGL auf dem M4 Mac Mini mit funktionierendem Compositing. Minecraft läuft mit 200 Frames pro Sekunde. Keines dieser Dinge sollte auf einem Linux-System ohne Treiber funktionieren, und beide funktionieren jetzt.
Das Duo dokumentierte ihre Arbeit außerdem in zwei Repositories unter Deliverables, wo sie alle ihre Experimente veröffentlichten. Der Sinn dahinter ist Transparenz: Jeder, der die Herkunft ihrer Arbeit überprüfen möchte, kann die Schritte selbst nachvollziehen.
Wie Sie Dorthin Gelangt Sind
Das Projekt begann mit einem Hypervisor, der es dem Team ermöglichte, zu beobachten, was macOS tut, wenn es mit der GPU kommuniziert. Von dort aus war der Ansatz einfach: das Betriebssystem beobachten, seine Aktionen wiederholen und dann versuchen, dasselbe von Grund auf neu zu machen.
Das LLM-Tool Codex half bei der Wiederholungsarbeit. Es erfasste den gesamten GPU-Speicherzustand, wenn ein Firmware-„Kick“ stattfand, und kopierte diesen Zustand nach einem Neustart zurück in den Hostspeicher. Anschließend versuchte das Tool, die Objekte im Code wiederaufzubauen, Zeigern zu folgen und den Inhalt zu interpretieren. Im Laufe der Zeit reduzierte Codex die Menge des wiederholten Zustands, bis alles aus dem Quellcode aufgebaut war.
Der Entwickler bemerkte, dass Codex gute Urteilskraft besitzt, wann die Hardware angesprochen und wann der Hypervisor ausgeführt und der Zustand selbst erfasst werden sollte. Diese Beobachtung wurde zu einem Schlüsselelement des Workflows.
Das Firmware-ABI-Problem
Der schwierigste Teil des Projekts war das Firmware-ABI. Apples GPU-Firmware verwendet ein benutzerdefiniertes RTOS namens RTKit, und der Kernel-Treiber kommuniziert damit über gemeinsam genutzten Speicher. Das bedeutet, dass das ABI auf zwei Welten aufgeteilt ist: dem eigenen Speicher des Firmware und dem Speicher des Hosts.
Viele der gemeinsam genutzten Strukturen haben firmware-eigene Felder, die der Treiber niemals verändern darf. Diese Felder müssen durch Reverse Engineering erlernt werden. Das ABI ist so kompliziert, dass der Entwickler es mit der M1/M2-Kernel-Treiber-Arbeit von Asahi Lina verglich und diese als „amazing“ bezeichnete.
Aber das Firmware-ABI des A18 Pro ist noch schwieriger. Es hat mehr Strukturen als die M1, mehr Zeiger und einen komplizierteren Prozess zum Einreichen von Aufgaben. Der Entwickler notierte die Komplexität in einer ungeschönten Bemerkung: „Was zum Teufel, Apple.“
Der Entwickler hatte einige Dokumente zum Firmware-ABI, aber diese waren hochgradig unvollständig und nicht sehr nützlich. Der Ansatz blieb derselbe: beobachten, was macOS tut, es wiederholen und dann von Grund auf neu aufbauen.
Die drei großen Probleme
Der Entwickler identifizierte drei Hauptprobleme während des Projekts, und alle führten auf dasselbe hinaus: ein sauberes Erfassen der Host-Arbeit zu erhalten.
- Render-Arbeit, die nach dem Start der GPU-Firmware eingereicht wurde, wurde bestätigt (ACKed) und zurückgezogen, ohne tatsächlich etwas zu tun.
- Render-Arbeit, die vor dem Start der Firmware eingereicht wurde, wurde bestätigt (ACKed) und zurückgezogen, ohne tatsächlich etwas zu tun.
- Arbeit, die während der Firmware-Startsequenz eingereicht wurde, wurde bestätigt (ACKed) und zurückgezogen, ohne tatsächlich etwas zu tun.
In jedem Fall war das Problem dasselbe: der Treiber konnte Befehle senden, aber die GPU würde sie nicht ausführen. Die Lösung war in jedem Fall, herauszufinden, was die Firmware erwartete und es bereitzustellen.
Der Clean-Room-Ansatz ()
Das Team behandelte Apples Blobs während des gesamten Projekts als undurchsichtige Objekte. Ein Freund verfasste die Dokumentation zu diesen Blobs, die das Team nutzte, um eine Clean-Room-Implementierung zu erstellen. Der Großteil der Arbeit im Benutzerbereich bestand darin, Dinge blind auszuprobieren, bis sie funktionierten. ()
Der Kernel-Treiber wurde im Gegensatz dazu von Grund auf neu aufgebaut, unter Verwendung ausschließlich von Hardware-Traces vom Hypervisor und Shadern, die das Team erstellte. Es gab kein „Hinterfragen“ der Apple-Binärdateien. ()
Dieser Unterschied ist wichtig. Die Reverse-Engineering-Arbeit für den Benutzerbereich-Grafik ist schwer, weil die Blobs geschlossen sind, aber die Kernel-ABI ist im Geiste, wenn nicht im Namen, öffentlich. Der Ansatz des Teams bestand darin, die beiden Seiten getrennt zu halten: der Benutzerbereich bleibt sauber, der Kernel-Bereich bleibt dokumentiert. ()
Was kommt als Nächstes ()
Der Treiber ist noch nicht für Endbenutzer bereit. Das Team möchte ihn aber so schnell wie möglich an sie weitergeben. ()
Die Arbeit ist auch noch nicht abgeschlossen. Der Plan umfasst Vulkan-Unterstützung über OpenGL hinaus. Das Team hat alle seine Experimente veröffentlicht, und die Repositories stehen weiterhin für jeden zur Verfügung, der die Herkunft seiner Arbeit überprüfen möchte. ()
Der Ansatz des Teams ist erwähnenswert. Sie haben ihre Misserfolge und Sackgassen nicht verborgen. Sie haben alles veröffentlicht, einschließlich der Experimente, die nicht funktioniert haben. Diese Art von Transparenz ist in diesem Bereich selten. ()
Warum das wichtig ist ()
Ein GPU-Treiber für Linux auf Apple Silicon ist ein großes Thema. Es bedeutet, dass die Open-Source-Welt mit diesen Chips kommunizieren kann, ohne sich auf Apples Binärdateien angewiesen zu sein. Es bedeutet, dass die Hardware nicht hinter undokumentierten Blobs gesperrt ist. ()
Die Tatsache, dass es nur einen Monat gedauert hat, ist die eigentliche Überraschung. Ein Monat ist eine enorme Verbesserung gegenüber Jahren, und das Team räumt ein, dass Tage zu optimistisch waren. Aber Wochen sind immer noch ein großer Erfolg. ()
Das Projekt zeigt auch, wie modernes Reverse Engineering aussieht. Es ist keine dunkle Kunst, die im Geheimen betrieben wird. Es ist ein transparenter, dokumentierter Prozess, dem jeder folgen kann. Die Verwendung des Hypervisors und Codex durch das Team ist ein praktisches Beispiel dafür, wie maschinelles Lernen bei der Arbeit mit Low-Level-Systemen helfen kann. ()
Die Arbeit ist beeindruckend. Die Transparenz ist bewundernswert. Und die Tatsache, dass Minecraft auf einem Linux-System mit 200 fps läuft, ist das Tüpfelchen auf der Torte.
Wer schon einmal ein Spiel auf einer nicht standardmäßigen Plattform ausführen wollte, kennt dieses Gefühl. Das Paar hat es geschafft, und sie nahmen das ganze Notebook mit auf die Reise.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.