I moduli kernel delle GPU NVIDIA per Linux sono distribuiti come open source con doppia licenza GPL/MIT dal maggio 2022, ma il driver che ne nasce non è del tutto libero: dipende da un firmware proprietario caricato a runtime e da uno stack user space chiuso. La differenza si fa sentire quando devi decidere su quale livello dello stack puoi davvero mettere le mani.

Contesto

Per quasi vent’anni il driver Linux di NVIDIA è stato un blob: un piccolo wrapper aperto (nvidia.ko) che agganciava nel kernel un binario proprietario. Chi gestisce macchine con queste schede conosce bene le conseguenze pratiche — il modulo “tainta” il kernel, non si ricompila, segue il ciclo di rilascio del vendor e le distribuzioni non riescono a impacchettarlo come fanno con i driver Mesa di AMD e Intel. In parallelo c’è nouveau, il driver libero nato dal reverse engineering, a lungo zavorrato dall’impossibilità di fare reclocking: senza le tabelle di gestione dell’alimentazione la GPU restava inchiodata a frequenze basse e rendeva una frazione del nominale.

Il 15 maggio 2022, con il rilascio R515, NVIDIA ha pubblicato i moduli kernel come sorgente sotto licenza GPL/MIT, nel repository NVIDIA/open-gpu-kernel-modules. È un cambio di policy reale, ma conviene leggere con precisione fin dove arriva quell’apertura.

Architettura

A rendere possibile l’apertura è il GSP, GPU System Processor: un coprocessore RISC-V comparso nelle GPU a partire dall’architettura Turing (2018). Funzioni che da sempre vivevano nel driver host — inizializzazione del chip, gestione di clock e alimentazione, scheduling di basso livello — sono passate nel firmware che gira sul GSP.

Lo spostamento ha due conseguenze. La prima: il codice che NVIDIA considera sensibile non sta più nel modulo kernel ma nel firmware, quindi il modulo si poteva aprire senza esporre quel codice. La seconda: il driver aperto pretende che il firmware GSP sia attivo. I moduli open-gpu-kernel-modules girano solo su Turing e successive, perché sull’hardware più vecchio il GSP non c’è e quelle funzioni dovrebbero tornare nel driver. La documentazione del repository lo dice senza giri di parole — i moduli aperti non coprono le GPU pre-Turing.

Il firmware GSP è un blob binario, dell’ordine delle decine di megabyte, distribuito a parte e versionato in lock-step con i moduli kernel e con le librerie user space. Le tre componenti devono combaciare esattamente nella versione.

Il punto critico

“Driver open source” non indica un singolo artefatto ma una pila a tre livelli, e l’apertura si ferma al primo:

  • Modulo kernel (nvidia.ko e correlati) — sorgente aperto, GPL/MIT, ricompilabile.
  • Firmware GSP — blob proprietario, eseguito sul coprocessore della GPU. Chiuso.
  • User space (runtime CUDA, OpenGL, il compilatore, le librerie di calcolo) — proprietario. Chiuso.

Il codice che pesa davvero per chi manda avanti carichi GPU non sta nel modulo kernel: sta in CUDA e nelle librerie collegate, tutte chiuse. Aprire il modulo kernel sistema i problemi di packaging e di integrazione con il kernel Linux — il modulo smette di essere un ostacolo per le distribuzioni e può seguire le interfacce interne del kernel — ma non rende ispezionabile né modificabile lo strato dove gira il lavoro vero.

Anche dentro il primo livello c’è una gradazione. Al rilascio R515 i moduli aperti erano dichiarati production-ready solo per le GPU data-center Turing e Ampere; per le schede GeForce e Workstation il supporto era alpha-quality, da abilitare come opt-in. La GPU sotto un desktop e la GPU in un nodo di training non si trovavano nello stesso stato di maturità.

Implicazioni

Per il software di sistema il GSP cambia anche il driver davvero libero. nouveau ha cominciato ad adottare il firmware GSP-RM pubblicato da NVIDIA: invece di reimplementare in spazio kernel la gestione di clock e alimentazione, carica lo stesso blob firmware e ci dialoga. Il risultato concreto è il reclocking automatico su Turing e successive — la GPU gira a piena frequenza sotto driver libero, cosa prima impossibile. Il prezzo è che ora anche il driver libero dipende da un blob proprietario, lo stesso da cui dipende il driver di NVIDIA.

Sul fronte grafico, all’inizio del 2024 NVK — il driver Vulkan open source per hardware NVIDIA dentro Mesa, scritto da Faith Ekstrand, Karol Herbst e Dave Airlie — ha raggiunto la conformità Vulkan 1.3 su Turing, Ampere e Ada, ed è stato dichiarato pronto per l’uso reale in vista di Mesa 24.1. Per quelle generazioni esiste per la prima volta uno stack grafico NVIDIA interamente aperto dal kernel allo user space, costruito però sopra il firmware GSP chiuso. Per il calcolo non c’è nulla di equivalente: non esiste un runtime CUDA libero, e gli stack di inferenza e training (PyTorch, le librerie del vendor) parlano con CUDA.

Una nota di giornata: oggi, alla GTC, NVIDIA ha annunciato l’architettura Blackwell — B200, GB200, sistemi rack-scale per modelli da migliaia di miliardi di parametri. Lo stack software che muove quell’hardware resta CUDA, chiuso. L’apertura del modulo kernel del 2022 non tocca quel livello, e niente nell’annuncio di oggi lo sposta.

Limiti

Tutto questo riguarda il driver Linux. Su Windows il modello resta interamente proprietario, e niente di quanto detto si applica. Anche su Linux i moduli aperti coprono solo Turing e successive: chi ha hardware Pascal o precedente, sul driver di NVIDIA, usa ancora il blob legacy.

Aprire il modulo kernel non è un gesto reversibile a piacere — il sorgente del 2022 resta pubblico — ma non implica nulla sul resto della pila. Le componenti chiuse (firmware GSP, runtime CUDA, compilatore, librerie) restano tali, e nel 2024 la maturità del modulo aperto varia tra data-center e consumer. “Open” descrive un livello dello stack, non lo stack.

Immagine di copertina: Macrofotografia del die in silicio della GPU NVIDIA Turing TU106 (GeForce RTX 2060), con i blocchi del processore visibili sulla… — foto di Fritzchens Fritz, CC0 — https://commons.wikimedia.org/wiki/File:Nvidia@12nm@Turing@TU106@GeForce_RTX_2060@S_TAIWAN_1844A1_PM4F79.000_TU106-200A-KA-A1_DSC07437-DSC07591_-_ZS-DMap_(50914099198).jpg