Il mondo Linux si trova ad affrontare un problema critico con le schede grafiche AMD di ultima generazione. Quella che doveva essere un'ampia analisi comparativa delle prestazioni delle GPU Radeon su kernel Linux 6.19 si è trasformata in una scoperta allarmante: le architetture RDNA3 e RDNA4 stanno subendo blocchi completi del sistema che rendono impossibile completare qualsiasi sessione di test. La situazione è particolarmente grave considerando che il problema ha raggiunto l'albero principale del kernel senza essere intercettato, nonostante sia facilmente riproducibile sotto carichi di lavoro grafici.
Michael Larabel, fondatore di Phoronix e figura di riferimento nel benchmarking su Linux, aveva pianificato un'estesa comparativa di fine anno per valutare le prestazioni delle schede video AMD attraverso diverse generazioni. Il test doveva includere GPU dalle prime GCN 1.0/1.1 fino alle recentissime RDNA4, utilizzando il kernel Linux 6.19 abbinato ai driver open-source Mesa 26.0-devel nelle loro varianti RADV, RadeonSI e Rusticl. L'occasione era particolarmente significativa dato che Linux 6.19 ha reso AMDGPU il driver predefinito anche per le vecchie architetture GCN di prima e seconda generazione.
Tuttavia, i test sulle schede più recenti hanno rivelato un problema sistemico: le GPU basate su architetture RDNA3 e RDNA4 vanno incontro a blocchi hardware completi quando sottoposte a benchmark grafici o computazionali. Il fenomeno non si limita a crash del driver o riavvii del sistema, ma si manifesta con veri e propri hang che impediscono anche l'accesso remoto al sistema e non lasciano tracce nei log del kernel salvati su disco.
La gravità della regressione è confermata dal fatto che anche gli sviluppatori driver di Valve hanno riscontrato lo stesso comportamento problematico. Il bug è presente sia su Linux 6.18 che sulla più recente versione 6.19, suggerendo che la causa risalga a modifiche introdotte alcune settimane fa. Nonostante l'impatto evidente e la facilità con cui il problema può essere riprodotto sotto carichi GPU, al momento non esiste ancora una correzione ufficiale da parte di AMD né qualcuno sembra aver effettuato una bisection del kernel per identificare il commit responsabile.
Di conseguenza, l'analisi pubblicata si concentra esclusivamente sulle generazioni precedenti, coprendo un arco temporale che va dal 2012 al 2023. Le schede testate includono la HD 7950 basata su GCN 1.0, passando per modelli intermedi come la R9 285 (GCN 2.0), la R9 290 (GCN 2.0), la RX 590 (Polaris), le Vega 56, fino ad arrivare alle più recenti architetture stabili: la serie RX 5000 (RDNA 1.0) con i modelli 5500 XT, 5700 e 5700 XT, la serie RX 6000 (RDNA 2) rappresentata da 6600, 6600 XT, 6750 XT, 6800 e 6800 XT, e concludendo con la RX 7600 XT basata su RDNA 3.
I test condotti coprono sia il rendering grafico tradizionale tramite OpenGL e Vulkan, sia il calcolo computazionale attraverso Vulkan compute e OpenCL con il driver Rusticl. Questa ampia copertura offre una panoramica completa delle prestazioni dello stack open-source AMD su Linux nelle sue varie componenti, anche se limitata alle architetture più datate a causa del problema riscontrato.
La situazione solleva interrogativi sulla qualità del testing pre-release del kernel Linux per quanto riguarda i driver grafici AMD. Che un bug così evidente e facilmente riproducibile sia finito nell'albero principale gestito da Linus Torvalds senza essere intercettato rappresenta un'anomalia significativa. Larabel ha definito questa la regressione AMDGPU più frustrante incontrata negli ultimi anni, sottolineando come il problema stia già generando lamentele nei forum da parte di giocatori e utenti Linux.
Per la comunità Linux e gli utilizzatori di schede AMD di ultima generazione, la situazione richiede attenzione: chiunque stia utilizzando GPU RDNA3 o RDNA4 dovrebbe evitare l'aggiornamento a kernel 6.18 o successivi fino a quando non verrà identificata e risolta la causa dei blocchi. Nel frattempo, rimane da vedere se AMD o la comunità di sviluppatori del kernel riusciranno a individuare rapidamente il commit problematico attraverso una bisection, un processo reso particolarmente laborioso dalla natura dei blocchi hardware che richiedono riavvii forzati del sistema.
