Asahi Linux: Rust-Magie macht Linux-Treiber für Apple-GPU möglich

Die GPU in Apple Silicon arbeitet wohl deutlich anders als vergleichbare Hardware. Die komplizierte Nutzung unter Linux wird durch Rust vereinfacht.

Artikel veröffentlicht am 30. November 2022, 10:00 Uhr, Sebastian Grüner

Der GPU-Kernel-Treiber von Asahi Linux läuft mit Rust. (Bild: Asahi Linux/CC-BY-SA 4.0)

Das Asahi-Linux-Projekt, das einen Linux-Port auf die Apple-Silicon-Hardware erstellt, hat einen ausführlichen Bericht zum Stand des Linux-Kernel-Treibers für die GPU veröffentlicht. Darin betont die hauptverantwortliche Entwicklerin Lina, dass eine Umsetzung des Treibers in C deutlich schwerer wäre, als dies nun in dem gewählten Rust der Fall ist. Grund dafür ist unter anderem der von Apple für die GPU genutzte Aufbau.

Dazu heißt es: "Normalerweise ist der GPU-Treiber für Details wie das Planen und Priorisieren von Arbeiten auf der GPU und das Unterbrechen (Preemption) von Jobs verantwortlich, wenn ihre Ausführung zu lange dauert, damit Apps die GPU fair nutzen können." Manchmal übernehmen die GPU selbst noch die Energieverwaltung und teilweise auch die Kommandoverarbeitung.

Oft genug sei die Arbeit an dem Treiber recht simpel. Denn diese bestehe meist nur aus der MMU und einem Command-Prozessor, der über Pointer direkt auf Buffer im Userspace zugreifen kann. So müsse der Treiber nicht viel mehr machen als die Speicherverwaltung und das Scheduling, wofür der Grafikteil des Linux-Kernels (DRM) zahlreiche Helfer bereit halte.

Die GPU des Apple Silicon nutzt aber einen Co-Prozessor (ASC). Dabei handelt es sich um eine komplette ARM64-CPU samt Echtzeitbetriebssystem. Die so umgesetzte Firmware verwaltet im Prinzip jede Funktion der GPU: Energieverwaltung, Scheduling und Preemption, Fault-Recovery, Perf-Counter, weitere Statistiken und sogar die Temperatur.

Rust als Rettung

Laut dem Bericht steuert der MacOS-Kernel-Treiber die GPU-Hardware dabei gar nicht selbst, was sehr unüblich ist. Vielmehr wird die GPU allein über die Firmware gesteuert, was wiederum über Datenstrukturen in einem geteilten Adressraum geschieht, auf den der MacOS-Kernel-Treiber zugreifen kann.

Nicht nur seien die Datenstrukturen selbst sehr vielfältig, diese enthielten oft auch selbst verschachtelte Datenstrukturen bis hin zu "Mikrosequenzen" kleinerer Befehle, die wie eine virtuelle CPU anmuteten, heißt es in dem Blog-Post. Der Linux-Kernel-Treiber müsse dies im Prinzip nachstellen. Insgesamt gebe es mehr als 100 dieser Datenstrukturen und die Firmware selbst übernehme keine Sanity Checks. Eine Falsche Nutzung führt also direkt zum Absturz.

Nach zahlreichen Arbeiten in Python, um sich den Datenstrukturen und Funktionen der GPU zu nähern, entschied sich Lina dafür, den Kernel-Treiber in Rust zu erstellen. Denn in Bezug auf eine Umsetzung in der für den Linux-Kernel üblichen Sprache C heißt es: "Es gibt zu viele Dinge, die man falsch machen könnte, und C hilft dabei überhaupt nicht!" Außerdem müssten auch verschiedene Firmware-Versionen unterstützt werden, wobei sich die Datenstrukturen je nach Version signifikant änderten. Das sei in C ebenfalls nur schwer umsetzbar.

Zu Rust heißt es jedoch: "Wenn Sie einen brandneuen Kernel-Treiber schreiben, der so kompliziert ist wie dieser, führt der Versuch, von einfachen Demo-Apps zu einem vollständigen Desktop mit mehreren Apps zu wechseln, die gleichzeitig die GPU verwenden, normalerweise zu allen möglichen Race-Conditions, Speicherlecks, Use-after-Free-Fehlern und anderen Arten von Schlechtigkeiten. Aber das alles ist einfach nicht passiert!" Lina folgert deshalb schlicht: "Rust ist magisch!"

Desktop läuft, Vulkan ist in Arbeit

Rust verringere außerdem die Anzahl an Fehler und leite zu einem sicheren und guten Design an. Mit Hilfe des bereits existierenden Userspace-Treibers konnte dann schnell ein Desktop dargestellt werden. Inzwischen unterstützt der Kernel-Treiber auch schon die M2-GPU. Ein Vulkan-Treiber ist bereits in Arbeit. Bis das Team die Komponenten zum Testen an seine Nutzer verteilt, wird aber wohl noch etwas Zeit vergehen. So soll erst das Userspace-API fertig gestellt werden, was für eine Aufnahme in Linux selbst wichtig ist. Außerdem gebe es noch Probleme bei der Leistung.