Linus Torvalds e l’IA trovano in una riga la soluzione a un bug delle GPU Intel Xe

Una modifica di una sola riga ha risolto un grave malfunzionamento del driver grafico Intel Xe sulle GPU Battlemage G21. Arrivare a quella riga, però, è stato tutt’altro che semplice: Linus Torvalds ha descritto l’indagine come una «sessione di debug dall’inferno», condotta con l’aiuto di un assistente IA attraverso 24 versioni di patch e 18 avvii del kernel.

La correzione: arrotondare verso il basso

Il bug riguardava il calcolo del confine tra la normale VRAM e lo spazio riservato al flat Compute Command Streamer (CCS), una struttura usata dall’hardware per i metadati della compressione. In termini concettuali, l’operazione è passata da:

round_up(value, SZ_128K)

a:

round_down(value, SZ_128K)

La differenza è fondamentale. Il valore rappresentava il limite finale della memoria che l’allocatore VRAM poteva usare. Arrotondandolo verso l’alto, il driver faceva apparire come libera una piccola porzione compresa tra il confine reale e quello arrotondato. Quella porzione, però, apparteneva allo spazio CCS riservato all’hardware, non alle normali allocazioni. Arrotondare verso il basso mantiene invece l’allocatore dalla parte sicura del limite.

Perché l’errore corrompeva la grafica

Quando l’allocatore iniziava a trattare lo spazio CCS come VRAM disponibile, le normali allocazioni potevano sovrapporsi ai metadati della compressione e sovrascriverli. La corruzione finiva per coinvolgere anche dati legati alle tabelle delle pagine della GPU, provocando artefatti sullo schermo e altri malfunzionamenti del sistema grafico. Su hardware Battlemage G21, GDM — il display manager utilizzato da diversi ambienti Linux — entrava inoltre in un ciclo di riavvii continui.

Non si trattava quindi soltanto di un errore aritmetico. Il problema era semantico: il codice allineava un valore come se fosse un indirizzo di partenza, anche se quel valore indicava il limite oltre il quale la memoria utilizzabile terminava. Ecco perché la soluzione finale è stata minuscola, mentre individuarla ha richiesto un’indagine molto più lunga.

Ventiquattro patch e 18 avvii per restringere il campo

Torvalds e l’assistente IA hanno aggiunto e modificato strumentazione mirata, seguito i calcoli della memoria nel driver e confrontato la posizione del CCS comunicata dall’hardware con il confine passato all’allocatore VRAM. Sono servite 24 versioni delle patch di debug e 18 cicli di riavvio e test prima che diventasse evidente l’errore nella direzione dell’arrotondamento.

Gli avvii ripetuti erano importanti perché il problema si manifestava a livello dell’hardware e del sistema grafico, non soltanto come una riga di codice sospetta. Ogni esperimento aiutava a distinguere il comportamento dell’allocatore da altre possibili cause degli arresti e della corruzione video.

L’IA ha accelerato il lavoro, ma non lo ha guidato

Torvalds ha utilizzato l’assistente come partner interattivo per il debug. Lo strumento ha contribuito a proporre la strumentazione, seguire i percorsi nel codice e analizzare i risultati degli esperimenti successivi, riducendo il lavoro ripetitivo necessario per verificare le varie ipotesi.

Ma l’assistente non si è dimostrato un’autorità affidabile. Secondo Torvalds, in più occasioni ha concluso che il problema fosse impossibile o irrisolvibile, suggerendo di limitarsi a scrivere un rapporto. È stato il programmatore a decidere quale esperimento eseguire dopo, riconoscere le interpretazioni errate e capire il significato dell’offset nel modello di memoria dell’allocatore.

È questo il dettaglio centrale della vicenda: l’IA ha generato possibilità e svolto il lavoro meccanico; l’esperto ha fornito il contesto, la perseveranza, i test verificabili e il giudizio finale.

La patch è nel kernel upstream, ma i backport vanno verificati

Torvalds ha scritto e inserito la correzione del driver Intel Xe nel kernel Linux upstream. Le informazioni disponibili indicano che le serie stabili ancora supportate dovrebbero ricevere la modifica attraverso il normale processo di backport, ma le fonti fornite non permettono di stabilire con affidabilità quali versioni stabili precise la includeranno né le relative date di rilascio.

Per questo sarebbe prematuro indicare numeri di versione specifici. Chi utilizza hardware interessato dovrebbe attendere gli annunci della propria distribuzione Linux o dei manutentori del kernel per verificare che una determinata build contenga effettivamente la soluzione.

La lezione per lo sviluppo del kernel con l’IA

Questo episodio non è un’approvazione generale del codice generato dall’IA per il kernel. Mostra piuttosto un utilizzo più circoscritto e difendibile: un esperto può impiegare l’IA per velocizzare un ciclo di debug difficile, mantenendo però la responsabilità dell’ipotesi, della progettazione dei test, della revisione e della patch finale.

È una situazione molto diversa dall’invio di patch o segnalazioni di vulnerabilità generate automaticamente, non richieste e non testate. I manutentori del kernel hanno parlato di una vera «offensiva» di contributi prodotti dai modelli linguistici; le segnalazioni provenienti dai manutentori di staging e networking descrivono una crescente frustrazione per patch di scarso valore o prive di una reale comprensione del sottosistema.

Anche il dato spesso citato di un aumento del 2.700% nelle submission va trattato con cautela: le fonti disponibili non chiariscono metodo di misurazione, periodo di riferimento o categoria precisa a cui si riferisca. La conclusione più solida è più generale: l’IA ha ridotto il costo di produrre codice e report, ma il tempo necessario per esaminarli e smistarli continua a ricadere sui manutentori umani.

Torvalds ha inoltre sostenuto che Linux non è pregiudizialmente contrario agli strumenti di IA, soprattutto quando vengono usati, per esempio, nella revisione del codice. La sessione di debug del driver Intel Xe mostra però il confine pratico: l’IA può essere utile all’interno di un processo ingegneristico disciplinato, ma non sostituisce la conoscenza del sottosistema, i test riproducibili o la responsabilità umana sul risultato.

La patch finale era lunga una riga. Il vero risultato è stato capire quale riga modificare — e continuare a cercare anche quando l’assistente sosteneva che la risposta non esistesse.