Intel propone DRM Fabric per Linux: così gestirà enormi reti di GPU AI

Le GPU dei grandi sistemi AI non lavorano più come dispositivi isolati collegati a una CPU. Nei server destinati a training e inferenza, decine o centinaia di acceleratori devono scambiarsi dati e accedere alla memoria remota con latenze molto basse, spesso attraverso collegamenti dedicati che aggirano i limiti delle tradizionali reti Ethernet. Linux deve quindi conoscere non soltanto quali acceleratori sono presenti, ma anche come risultano fisicamente collegati tra loro, quali porte sono operative e quale dispositivo si trova dall’altra parte di ogni collegamento.

È proprio il problema che alcuni ingegneri Intel vogliono affrontare con DRM Fabric, una nuova proposta presentata a fine agosto 2026.

Il nome può trarre in inganno: DRM, in questo caso, non ha nulla a che vedere con la protezione dei contenuti digitali (Digital Rights Management). Fa invece riferimento al Direct Rendering Manager, sottosistema del kernel Linux che da decenni gestisce una parte fondamentale dell’interazione con GPU, memoria grafica, display e acceleratori.

La proposta arriva mentre il calcolo AI sta spingendo Linux verso configurazioni hardware molto più articolate rispetto alla classica macchina con una o due GPU. Pochi giorni fa AMD aveva pubblicato una corposa serie di patch per integrare UALink nel driver AMDGPU: il lavoro comprende circa 95 patch per l’infrastruttura principale, oltre a un secondo gruppo dedicato all’interfaccia IOCTL per importare ed esportare memoria. UALink 1.0 permette di costruire domini scale-up fino a 1.024 acceleratori e prevede collegamenti da 200 Gbps per lane. Il kernel sta insomma iniziando ad affrontare esplicitamente un problema destinato a diventare comune nei server AI di fascia alta.

Che cos’è DRM Fabric e perché Intel lo propone

DRM Fabric non rappresenta un nuovo protocollo per collegare fisicamente le GPU. Ciò che Intel caldeggia è invece un’infrastruttura comune a livello di kernel Linux capace di descrivere la topologia delle interconnessioni fra acceleratori gestiti da DRM, senza dipendere dal produttore e senza imporre uno specifico protocollo hardware.

Un driver potrebbe quindi utilizzare DRM Fabric per rappresentare collegamenti basati su UALink, AMD xGMI o tecnologie future.

La proposta nasce volutamente come “protocol-agnostic“: il kernel espone agli strumenti in userspace una rappresentazione coerente della fabric, mentre il driver del produttore continua a occuparsi della parte realmente legata all’hardware.

Il modello suggerito dagli sviluppatori Intel segue una gerarchia molto semplice: fabric, endpoint, port e peer. Una fabric identifica una specifica istanza dell’interconnessione; al suo interno compaiono uno o più endpoint, ciascuno associato a un acceleratore e alle relative porte fisiche.

La porta descrive caratteristiche come capacità delle lane, stato operativo e, quando disponibili, contatori statistici. Il peer identifica invece ciò che si trova direttamente all’altro capo della connessione: potrebbe essere un’altra GPU, la porta di uno switch oppure persino un componente che Linux non può gestire direttamente.

Fabric, endpoint, port e peer: il modello diventa interessante sui grandi server

La scelta di rappresentare separatamente i peer non è soltanto una finezza architetturale: un acceleratore potrebbe essere collegato a un dispositivo controllato da un altro sistema operativo oppure a uno switch appartenente a un differente dominio di gestione. DRM Fabric non pretende quindi che ogni elemento della topologia corrisponda a un oggetto Linux vivo e pienamente controllabile.

Si può immaginare un server con 8 GPU collegate direttamente oppure una macchina molto più grande con acceleratori distribuiti dietro diversi switch. Il kernel potrebbe esporre, per ciascuna GPU, le porte disponibili e il vicino direttamente raggiungibile. Un’applicazione di amministrazione avrebbe così una visione uniforme della struttura fisica senza conoscere le peculiarità del driver Intel, AMD o di un altro produttore.

DRM Fabric si ferma però, proprio per scelta progettuale, all’adiacenza diretta: se la GPU A raggiunge uno switch e quello switch conduce alla GPU B, il core DRM Fabric non calcola automaticamente il percorso completo A-switch-B. Instradamento end-to-end e forwarding degli switch restano compiti del controller della fabric e delle componenti specifiche del produttore.

Gli sviluppatori cercano di evitare un errore abbastanza comune nelle API di sistema: trasformare un’interfaccia nata per descrivere lo stato dell’hardware in un enorme livello universale che finisce per duplicare logiche già presenti nei driver o nel firmware.

Per Linux il problema non è collegare le GPU, ma descriverle tutte allo stesso modo

DRM Fabric potrebbe sembrare una modifica molto specialistica del kernel, lontana dall’esperienza quotidiana degli utenti Linux.

In realtà fotografa bene il modo in cui stanno cambiando i sistemi di calcolo ad alte prestazioni. Una GPU non è più necessariamente una periferica collegata a un bus PCIe e controllata quasi esclusivamente dal proprio driver: può diventare un nodo di una rete locale di acceleratori, con memoria condivisa o remota e numerosi collegamenti verso GPU e switch.

Linux possiede già i meccanismi specifici necessari per gestire molte di queste tecnologie: ciò che manca è una rappresentazione sufficientemente generale delle relazioni fra i dispositivi. Ed è precisamente il vuoto che DRM Fabric cerca di colmare.

La parte forse più interessante della proposta Intel non riguarda quindi una particolare GPU. Riguarda l’idea che la topologia degli acceleratori diventi una risorsa del sistema operativo, interrogabile e in alcuni casi configurabile attraverso una uAPI stabile.

Se la discussione sulla mailing list DRM porterà all’integrazione nel kernel, strumenti di gestione e orchestrazione potranno vedere fabric hardware differenti attraverso lo stesso modello logico. DRM Fabrica permetterà a Linux di parlare una lingua comune quando dovrà descrivere l’insieme degli acceleratori.