Linux su Apple M4 accelera: un driver GPU completo nasce in appena un mese

Portare Linux sui Mac basati su chip Apple Silicon non significa soltanto riuscire ad avviare il kernel. Senza un driver grafico capace di dialogare con la GPU, anche una macchina molto potente finisce per affidarsi al rendering software sulla CPU, con prestazioni e consumi lontanissimi da quelli ottenibili con hardware specializzato.

È proprio su uno dei componenti più difficili da ricostruire che Cody Ho e Niklas Sheth hanno concentrato il loro lavoro: in circa un mese hanno sviluppato uno stack grafico Linux per i sistemi Apple più recenti, arrivando a eseguire un’implementazione dichiarata conforme a OpenGL ES 3.0 su Mac Mini M4 e MacBook Neo.

Il risultato colpisce anche per la velocità con cui è arrivato. Il progetto Asahi Linux aveva già dimostrato quanto fosse complesso costruire driver aperti per i chip Apple M1 e M2: il lavoro iniziato da Alyssa Rosenzweig, Asahi Lina e altri sviluppatori aveva richiesto anni di reverse engineering prima di raggiungere la conformità OpenGL ES 3.1 e poi OpenGL ES 3.2 e OpenGL 4.6 sulle prime generazioni Apple Silicon.

C’è però un elemento che cambia radicalmente il metodo di lavoro: Ho e Sheth hanno affidato una quota molto ampia dell’analisi, della produzione del codice e degli esperimenti a coding agent basati su modelli linguistici. Gli agenti hanno avuto accesso a strumenti con cui formulare ipotesi, interrogare l’hardware, registrare i risultati, confrontarli e riprovare. In pratica, il modello non lavorava soltanto su testo e sorgenti, ma dentro un ciclo sperimentale collegato a macchine Apple reali.

Come hanno studiato la GPU integrata nei SoC Apple Silicon

Apple M4 non è una GPU, ma un SoC che integra CPU, GPU, Neural Engine, controller di memoria e altri blocchi specializzato.

Il lavoro di Cody Ho e Niklas Sheth riguarda quindi in modo specifico il sottosistema grafico AGX integrato nei SoC Apple Silicon più recenti. Per capire come macOS comunica con la GPU, Ho ha utilizzato un hypervisor che gli permetteva di eseguire il sistema operativo sotto controllo e intercettare le operazioni dirette all’hardware.

Il metodo ricorda quello utilizzato da Asahi Linux con m1n1, ma sulle generazioni più nuove servivano strumenti diversi anche per la presenza di ulteriori meccanismi di protezione introdotti da Apple.

Gli sviluppatori catturavano una transazione valida, la riproducevano e rimuovevano progressivamente ciò che non serviva, fino a isolare strutture, descrittori e comandi importanti. In un caso una cattura aveva raggiunto 336 MB, perché macOS aveva già inizializzato numerose strutture e accumulato molto stato interno della GPU.

La soluzione è stata avviare il sistema in modalità single-user ed eseguire subito un piccolo programma Metal, così da ottenere una traccia molto più semplice da analizzare. Gli LLM hanno accelerato proprio questa fase ripetitiva: modificare campi, rilanciare test, confrontare risultati e formulare nuove ipotesi. Va detto però che non lavoravano davvero “da soli”: Ho racconta diversi casi in cui gli agenti insistevano su piste sbagliate o affrontavano problemi troppo complessi prima di quelli essenziali.

Perché scrivere un driver per la GPU Apple è così difficile

Per usare una GPU è necessario interfacciarsi con più livelli software: Mesa (principale progetto open source che fornisce su Linux le implementazioni delle API grafiche come OpenGL e Vulkan e l’infrastruttura user space usata da molti driver GPU) semplifica una parte enorme di questo secondo lavoro grazie a Gallium3D, che espone un’interfaccia comune per i driver grafici e a NIR, una rappresentazione intermedia usata durante la compilazione degli shader.

Uno shader è un piccolo programma eseguito direttamente dalla GPU per calcolare elementi della scena grafica, ad esempio colori, illuminazione, texture, geometria ed effetti visivi.

Con AGX, compare inoltre un livello particolarmente scomodo. Il driver del sistema operativo non controlla direttamente ogni dettaglio dell’hardware: un coprocessore ARM esegue firmware Apple e gestisce funzioni fondamentali, tra cui scheduling, power management, recupero dagli errori e comunicazione con varie unità della GPU.

Parlando di ABI (Application Binary Interface) del firmware, insieme di strutture dati, campi, messaggi e convenzioni che il driver deve rispettare per comunicare correttamente con il coprocessore, non esiste una specifica pubblica Apple da seguire. Per costruire un driver indipendente bisogna osservare ciò che fa macOS, comprendere quali strutture prepara, quali indirizzi passa al firmware e come interpreta gli eventi di completamento.

Il problema si complica sulle generazioni più recenti. Cody Ho riferisce che l’ABI studiata sul chip A18 Pro contiene circa una volta e mezzo il numero di strutture e circa il doppio dei puntatori rispetto a quella ricostruita per M1 e M2; anche il meccanismo di invio del lavoro risulta più articolato. Inoltre, secondo l’autore, M4 e A18 Pro condividono una user space molto simile, ma differiscono parecchio sul lato firmware. M5 introduce ulteriori variazioni, comprese differenze nei descrittori delle texture.

Dal reverse engineering al driver Linux per la GPU del chip M4

Una volta ricostruiti abbastanza dettagli sul funzionamento della GPU e sul dialogo con il firmware, il progetto è passato dai prototipi a un vero driver Linux scritto in Rust.

Il driver gestisce l’invio dei workload alla GPU, la memoria e la sincronizzazione delle operazioni, mentre la parte user space si appoggia a Mesa. Ho e Sheth hanno inoltre realizzato un compilatore capace di trasformare gli shader in istruzioni comprese dall’architettura grafica AGX.

Invece di tentare di documentare subito ogni dettaglio della GPU, hanno usato i test Khronos per individuare le funzioni mancanti e procedere una alla volta.

Il risultato dichiarato è proprio la conformità OpenGL ES 3.0 sulla GPU integrata nel chip M4, con dimostrazioni che vedono Minecraft in esecuzione a oltre i 200 fps sul Mac Mini M4 e WebGL accelerato in Chrome e Firefox.

Il lavoro, però, non è concluso: il codice resta sperimentale, deve affrontare una serie di attività di revisione e pulizia prima di un’eventuale integrazione nei progetti principali, mentre tra gli obiettivi successivi compaiono Vulkan 1.4, OpenGL 4.6 e OpenGL ES 3.2.