In questo articolo Indice dei contenuti 3 sezioni
Una VRAM danneggiata non è più necessariamente una condanna per l’intera scheda grafica, almeno stando al lavoro che Intel sta portando avanti sul driver grafico Xe per Linux. L’azienda ha messo in cantiere una serie di modifiche pensate per il ciclo di sviluppo di Linux 7.4, con due obiettivi piuttosto chiari: verificare lo stato della memoria video già all’avvio e, quando serve, mettere definitivamente da parte le pagine fisiche riconosciute come difettose. Nessuna magia sull’hardware, sia chiaro. Il silicio rotto resta rotto. Quello che cambia è il modo in cui il software decide di conviverci.
Il punto di partenza è abbastanza pragmatico. Anomalie nella memoria video possono tradursi in corruzione dei dati, blocchi improvvisi del dispositivo o comportamenti strani durante l’uso della GPU. Intervenire a livello di driver significa provare a intercettare il problema prima che faccia danni, isolando le aree sospette e impedendo che tornino in circolo.
Un controllo sulla memoria video già durante l’avvio
La prima novità riguarda un controllo di integrità eseguito durante l’inizializzazione del driver Xe. Il meccanismo sfrutta l’ultima pagina della memoria video come canary, cioè come sentinella: quella porzione viene sottoposta a verifiche mirate a scovare anomalie nella configurazione. Secondo l’ingegnere Intel Matthew Auld, si tratta di una posizione particolarmente adatta per far emergere problemi legati al dimensionamento del BAR, della CCS e delle mappe di memoria.
Non è un’idea nata a tavolino. L’esigenza è emersa da un caso concreto osservato su alcune GPU Battlemage, dove un offset CCS configurato male poteva far finire una parte dello spazio riservato ai dati di compressione dentro l’area che l’allocatore della VRAM considerava libera e utilizzabile. Un pasticcio silenzioso, difficile da individuare a posteriori. Il test iniziale serve appunto a far saltare fuori la condizione errata prima che quella memoria venga impiegata nel normale funzionamento.
Per ora la funzione resta dietro l’opzione di compilazione CONFIGDRMXEDEBUGMEM, il che significa che non è destinata ad attivarsi sulle configurazioni di produzione. Strumento da laboratorio, insomma, almeno in questa fase.
Pagine difettose messe fuori gioco in modo permanente
Il secondo intervento affronta invece il guasto vero e proprio. Dopo ben 21 revisioni del codice, Xe ha incassato il supporto al memory page offlining, funzione che permette di rimuovere in modo permanente una pagina fisica difettosa dal bacino usato per le nuove allocazioni. Le aree escluse vengono poi esposte tramite DebugFS, così che gli strumenti in spazio utente possano sapere quali porzioni della memoria video risultano compromesse.
Il paragone più immediato è con i settori danneggiati su un disco. Quando il driver individua una pagina inutilizzabile, semplicemente smette di restituirla alle richieste successive. Risultato: una singola area guasta non manda in crisi tutto lo spazio video disponibile e la scheda grafica continua a lavorare appoggiandosi alle porzioni ancora sane. Il prezzo da pagare è evidente e viene detto senza giri di parole, perché la quantità di memoria effettivamente utilizzabile cala in proporzione alle pagine messe offline.
Capacità insufficiente e guasto fisico restano due cose diverse
Vale la pena tenere separati i due scenari, perché vengono spesso confusi. La pressione sulla memoria video è una questione di capienza: le applicazioni chiedono più di quanto ci sia a disposizione e il sistema deve arrangiarsi. Un guasto fisico è tutt’altra faccenda, riguarda l’affidabilità di una specifica zona della memoria che smette di comportarsi come dovrebbe.
Il nuovo meccanismo di Intel si occupa del secondo caso, agendo direttamente a livello di driver per impedire che la porzione compromessa venga riutilizzata. Un’aggiunta che sposta il baricentro del lavoro su Xe verso il terreno dell’affidabilità, più che delle prestazioni pure.
Fonte: TecnoAndroid
