Marted� sera Arnd Bergmann ha inviato a Linus Torvalds la pull request con gli aggiornamenti SoC per Linux 7.3: poco pi� di mille commit non-merge, 263 autori, 1088 file modificati, oltre 70.000 righe aggiunte e circa 7.200 rimosse. La maggior parte del volume arriva dai file devicetree di Qualcomm, NXP e Rockchip. Dentro ci sono l’abilitazione di Apple M3 Pro, Max e Ultra, che porta i Mac fino alla console e non oltre, un SoC Qualcomm che l’azienda non ha ancora annunciato e la messa in preavviso di un gruppo di piattaforme Arm a 32 bit.
Bergmann ha ripreso una serie precedente e ha etichettato ci� che ostacola pulizie e nuove funzionalit� pur avendo quasi zero utenti, e i test gi� condotti hanno fatto emergere centinaia di driver orfani, rimovibili insieme alle piattaforme che li impiegano. Il taglio effettivo arriver� in una release successiva, il 7.4 o oltre, e le patch di rimozione sono gi� in fase di test.
Nello stesso ciclo entra la prima parte del lavoro di Natalie Vock sulla gestione della memoria video, accettato a monte dopo mesi di passaggi in mailing list e gi� presente nel kernel di SteamOS. Vock, che lavora per Valve sul supporto grafico Linux, aveva descritto le modifiche in un primo intervento all’inizio dell’anno, promettendo un comportamento molto pi� stabile dei giochi a patto che il gioco non chiedesse pi� VRAM di quanta ne esista fisicamente sulla scheda. Il nuovo lavoro parte da quell’eccezione, e mostra che finire la memoria video non produce soltanto un calo di prestazioni: un gioco che ne chiede 9 GB su una scheda da 8 pu� restare giocabile, mentre un deadlock nel kernel manda in errore l’invio dei comandi alla GPU.
Le piattaforme Arm a 32 bit messe in preavviso
Il primo gruppo riguarda 22 dei 28 board file legacy ancora presenti, quelli che precedono la descrizione via devicetree e che usano vecchi chip Intel e Marvell. I sei board file superstiti coprono i TI OMAP1 e i Samsung s3c64xx, e hanno tutti utenti noti. Il secondo gruppo tocca il supporto ai core Cortex-M3, M4 e M7 e ad ARM1136r0, insieme alle 25 macchine che li montano.
Le 25 macchine usano gi� devicetree, ma il supporto alle CPU costa un lavoro sproporzionato rispetto alla diffusione. Si tratta quasi sempre di schede di riferimento, con due eccezioni che Bergmann segnala: il tablet Nokia N800/N810 e la piattaforma Buglabs BUG. Il terzo gruppo riguarda invece lo userspace: i binari be8, be32, oabi e iwmmxt, legati in gran parte alle stesse piattaforme e sempre pi� difficili da mantenere con i toolchain moderni.
“Nulla viene effettivamente rimosso a questo punto, per garantire che gli eventuali utenti rimasti continuino ad avere il 7.3-LTS ancora per un po’”, scrive Bergmann nella pull request. “Le patch per la rimozione sono attualmente in fase di test”. Chi ha ancora in esercizio uno di quei sistemi ha davanti una release a supporto esteso su cui restare mentre il codice sparisce dal ramo principale.
I nuovi SoC, dai Mac M3 al Qualcomm Shikra
L’elenco dei SoC che entrano in mainline comprende Apple M3 Pro, Max e Ultra, Samsung Exynos 1580, Canaan K210, Sophgo SG2000, Qualcomm Shikra e Altera Agilex72, quest’ultimo con core Cortex-A720. Bergmann osserva che si tratta in prevalenza di chip non recentissimi. Fa eccezione Shikra, un SoC basato su Cortex-A78C di cui circolano poche informazioni pubbliche e che Qualcomm non ha ancora presentato.
L’abilitazione di M3 Pro, Max e Ultra completa il lavoro sull’M3 base, entrato nel ciclo precedente. Il livello raggiunto resta quello dell’avvio: si arriva alla console, mentre l’uso quotidiano non � praticabile perch� manca il driver GPU e molte altre funzioni non sono ancora collegate sui Mac M3. Dallo stesso pull arriva un miglioramento per M1 Pro, Max e Ultra, che in s2idle raggiungono stati di consumo pi� bassi e risparmiano circa 1 W.
Il Sophgo SG2000 � un SoC ibrido Arm/RISC-V destinato a telecamere di sorveglianza, sistemi di riconoscimento facciale e dispositivi per la casa connessa, e mette insieme un core C906 a 1 GHz, un secondo C906 a 700 MHz e un Cortex-A53 a 1 GHz: la parte Arm era gi� supportata in mainline, ora si aggiunge quella RISC-V. Sul fronte schede entrano la Milk-V Duo 256M, basata sul SoC SG2002 con 256 MB di memoria, e la variante Milk-V Duo S. Fra le nuove macchine Arm supportate ci sono il Lenovo ThinkEdge SE70, costruito attorno al modulo NVIDIA Jetson Xavier NX con sei core Carmel, GPU Volta e 8 o 16 GB di LPDDR4x, insieme ad Anbernic RG Vita-Pro, HINLINK H28K, Youyeetoo YY3588, Sony Xperia M2 e NetCube Systems OpenNMC.
Cosa succede quando la VRAM finisce
I driver grafici permettono da sempre di chiedere pi� memoria video di quella presente sulla scheda: il kernel accetta la richiesta e sistema in VRAM quello che ci sta, spostando il resto nella RAM di sistema. Quella memoria resta accessibile alla GPU, ma il percorso passa dal bus PCI, che aggiunge latenza ed � quasi sempre anche il collo di bottiglia sulla banda. Il risultato dovrebbe quindi essere un problema di prestazioni, non di stabilit�.
Con un collegamento PCIe 4.0 x16 la banda disponibile � poco meno di 32 GiB/s, circa 32,2 MiB per millisecondo. Un frame a 30 fps dura 33,3 millisecondi, quindi in un singolo frame la GPU riesce a leggere al massimo 1.075 MiB di dati fuori dalla VRAM, poco pi� di un gigabyte: pescarne di pi� significa mancare i 30 fps per aritmetica, prima ancora che per qualit� del driver. Quel tetto vale per� solo per i dati che la GPU legge davvero, e non tutte le allocazioni vengono lette allo stesso modo: i command buffer restano a volte in RAM di sistema anche quando la VRAM abbonda, senza che nulla rallenti in modo percepibile, perch� quegli accessi cadono quasi sempre in cache, e di certe allocazioni la GPU tocca solo una piccola parte. Le misure su RDNA3 mostrano dove cade il confine: finch� il buffer entra nella L2 da 6 MB le latenze sono identiche per memoria di sistema e memoria della scheda, mentre una lettura che finisce sul bus PCIe costa circa 7,3 volte un colpo in Infinity Cache e 4,6 volte una lettura dalla VRAM.
Finire la VRAM porta con s� anche problemi di stabilit�. RADV stampa radv/amdgpu: Not enough memory for command submission quando il kernel risponde -ENOMEM all’invio dei comandi alla GPU, ma l’invio non alloca nulla di nuovo: i command buffer erano gi� stati allocati prima, e quelle allocazioni erano andate a buon fine. Prima di far partire il lavoro sulla GPU, amdgpu verifica che tutta la memoria potenzialmente toccata dai comandi sia accessibile, e con le API bindless questo significa tutta la memoria allocata. Quasi tutte le allocazioni vanno bene sia in VRAM sia in RAM di sistema, ma alcune devono stare in VRAM e basta: se nel frattempo sono uscite dalla scheda perch� un’altra applicazione ne ha occupato la memoria, il driver deve riportarle indietro, e per farlo deve spostare fuori qualcos’altro. � quel secondo spostamento a fallire, e il fallimento torna all’applicazione come memoria esaurita.
Per spostare un’allocazione bisogna prendere il lock associato, ma durante un invio il driver blocca gi� tutte le allocazioni citate, per impedire che un’altra applicazione le muova mentre prepara il lavoro. Due invii concorrenti che si contendono lock incrociati producono un deadlock ABBA da manuale, e il kernel sa riconoscerlo: una delle due transazioni viene marcata come ferita e al lock successivo riceve -EDEADLCK, che chiede di rilasciare tutti i lock presi e ricominciare la transazione da capo. Nel sottosistema grafico il giro di rilascio e ripetizione � incapsulato in una piccola libreria, drm_exec, che solleva il driver dal tenere il conto a mano dei lock acquisiti. TTM, il livello condiviso di gestione della memoria delle GPU su Linux, non la usa, e nel suo codice c’� perfino un commento che annota come -EDEADLCK faccia fallire lo spostamento: sotto forte pressione di memoria il kernel rinuncia a riprovare e rifiuta l’invio.
Agganciare drm_exec a TTM non � un’idea nuova: le prime serie di patch risalgono al 2024 e non entrarono mai, anche per alcuni bug rimasti irrisolti. Vock ha ripreso quel lavoro riportandolo sulla propria versione di kernel, e la parte pesante � stata proprio individuare quei bug: una settimana di giochi che si bloccavano dopo tre minuti di forte contesa sulla memoria. Le patch sono tornate in lista con le correzioni trovate, ma per essere integrate serve ancora altro lavoro.
Vock documenta una prova con Indiana Jones: The Great Circle, con impostazioni spinte fino a chiedere circa 9 GB di memoria video su una scheda che ne ha 8: con un gigabyte oltre la capienza il gioco � rimasto giocabile. “In molti casi si pu� restare sorpresi da quanta prestazione si riesca a conservare anche spostando fuori un gigabyte o pi� di memoria”, scrive, e qualifica subito il risultato: “� ovviamente un caso piuttosto ottimistico, e la cosa sbagliata che finisce nella RAM di sistema pu� causare rallentamenti molto pesanti”. Il codice descritto � gi� nel kernel di SteamOS, sui canali stable e preview, mentre a monte con Linux 7.3 entra solo la prima parte: il resto, drm_exec dentro TTM compreso, � raccolto in un branch dedicato, vramstuff-rebase, per chi vuole provarlo prima che arrivi in una versione futura del kernel.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
