A maggio il Khronos Group ha presentato OpenCL 3.1, un aggiornamento incrementale con un focus esplicito su carichi di intelligenza artificiale e HPC. Due mesi dopo, la prima implementazione a superare la suite di test di conformità non arriva da AMD, Intel o NVIDIA, ma dal driver Rusticl integrato in Mesa, in esecuzione su Apple Silicon M1 ed M2 con la distribuzione Asahi Linux.

La notizia segna un passaggio sottile ma rilevante. Da un lato, dimostra la maturità della pila open source per l’elaborazione parallela su hardware che fino a poco tempo fa era confinato al mondo macOS. Dall’altro, evidenzia come i tradizionali equilibri del calcolo eterogeneo stiano cambiando: la prima implementazione di una nuova specifica non viene più da un fornitore di hardware o da un ISV consolidato, ma da un progetto guidato dalla comunità e scritto in Rust, linguaggio che introduce garanzie di sicurezza della memoria in un dominio notoriamente esposto a instabilità e falle.

Rusticl, sviluppato all’interno dell’ecosistema Mesa, è un driver OpenCL che sfrutta il compilatore Rusticl per tradurre i kernel su GPU. Il fatto che abbia raggiunto la conformità su un SoC Apple non è un dettaglio tecnico fine a sé stesso. Mette in luce come l’accelerazione GPGPU su architetture ARM64, con driver liberi, stia diventando una realtà concreta anche al di fuori dei datacenter tradizionali. La scelta di Asahi Linux come piattaforma di test – un progetto che porta Linux nativamente sugli Apple Silicon – rende questo traguardo ancora più indicativo: si sta costruendo una base per un ecosistema di calcolo che abbraccia desktop, workstation e potenzialmente piccoli cluster basati su Mac Mini o Mac Studio.

Per chi valuta deployment on-premise o in edge computing, il punto non è se oggi un cluster di Apple Silicon possa competere con una configurazione di GPU datacenter: la domanda cruciale è quali carichi di lavoro possano essere gestiti localmente, in modo sovrano, senza dipendere da API cloud o da stack software chiusi. La conformità a OpenCL 3.1 — con le sue estensioni per AI e HPC — apre la strada all’esecuzione di inference, pre-elaborazione dati e simulazioni su hardware che molte organizzazioni già possiedono, con un sistema operativo aperto e driver controllabili.

Osservando la vicenda da una prospettiva strutturale, si intravede un’inversione nei percorsi di adozione degli standard di calcolo. In passato, le specifiche Khronos venivano implementate prima dai produttori di silicio, poi eventualmente dai progetti open source. Qui il processo si è ribaltato: la comunità ha prodotto il primo driver conforme, mentre i vendor restano per ora assenti. È un segnale che, quando l’hardware diventa accessibile e ben documentato (grazie anche al reverse engineering di Asahi), il software libero può prendere l’iniziativa.

C’è poi il fattore Rust. L’adozione di un linguaggio memory-safe in un componente di sistema come un driver grafico/compute non è una scelta estetica: riduce la superficie d’attacco e la probabilità di crash legati a puntatori non validi, un aspetto non secondario quando si pensa a workload continui di inference in produzione. Se Rusticl diventerà un riferimento, altre implementazioni potrebbero seguirne l’esempio, accelerando un ricambio generazionale nelle fondamenta software dell’elaborazione parallela.

In definitiva, la conformità di Rusticl su Apple M1/M2 non è solo una curiosità per appassionati di Linux su Mac. Delinea un’alternativa credibile per organizzazioni che cercano flessibilità hardware, controllo del software e indipendenza dai fornitori, in un momento in cui la corsa all’AI rende ogni opzione di calcolo locale meritevole di attenzione.