Il kernel Linux 7.3-rc1 viaggia verso i 41 milioni di righe e il driver grafico AMD, da solo, supera i 6,5 milioni. La notizia non è solo numerica: Linus Torvalds ha segnalato che le modifiche al driver AMD pesano per circa un terzo dell'intera release candidate, spinte dai grandi file di registro della GPU per DCN 6.0 e da altre nuove proprietà intellettuali. È un dettaglio che racconta molto su come l'abilitazione dell'hardware stia cambiando il baricentro del kernel.

I file di registro delle GPU non sono codice scritto a mano nel senso tradizionale: sono in gran parte generati a partire dalle specifiche del silicio. Quando AMD inserisce blocchi come DCN 6.0, il contributo upstream si traduce in decine o centinaia di migliaia di righe di definizioni di registri, spesso con poca logica procedurale. Questo ha un effetto duplice. Da un lato accelera il supporto per nuovo hardware e riduce la necessità di driver proprietari out-of-tree; dall'altro aumenta il carico di revisione, la superficie di attacco e la complessità di manutenzione per chi mantiene il kernel. Non è un problema teorico: una modifica sbagliata in un registro può compromettere stabilità o sicurezza, e la dimensione del codice rende più difficile isolare i problemi.

Per chi gestisce infrastrutture on-premise, in particolare per carichi di inference e training di LLM, questo dato non è secondario. Le GPU AMD sono una delle opzioni per costruire nodi di calcolo self-hosted. Il fatto che il supporto nel kernel sia upstream e in crescita significa che le distribuzioni Linux possono includere il driver senza dipendere da moduli esterni, un vantaggio per la riproducibilità degli ambienti e per la conformità a politiche che richiedono software auditable. Ma la dimensione e la velocità di evoluzione del driver impongono un presidio: aggiornamenti del kernel, patch di sicurezza e compatibilità con i runtime user-space diventano variabili da governare. In un deployment on-premise, dove il controllo del ciclo di vita è in capo al team locale, la complessità del driver si trasforma in costo operativo.

C'è un terzo livello di lettura, più strutturale. La crescita del driver grafico AMD non è un'anomalia, ma un sintomo della direzione dell'hardware acceleration. Le nuove IP per display, media e calcolo portano con sé un'enorme quantità di stato configurabile, e il kernel Linux è diventato il punto di convergenza per questa complessità. Se la tendenza continua, assisteremo a release candidate sempre più dominate da contributi generati da vendor, con un effetto di crowding out sul codice condiviso e sulle architetture più leggere. Per chi valuta piattaforme per AI on-premise, questo segnala che la scelta dell'hardware non è separabile dalla strategia del software di sistema: il driver non è un dettaglio, ma parte dell'infrastruttura.

Per leggere questi trade-off in un framework più ampio, AI-RADAR offre framework analitici su /llm-onpremise, dove si confrontano i vincoli di hardware, driver e gestione locale. La prossima release stabile dirà quanto di queste modifiche reggerà il ciclo; intanto i numeri di rc1 sono già un indicatore di pressione sul processo di sviluppo.