Come verificare che una GPU integrata sia ancora disponibile dopo un aggiornamento del kernel
Una GPU integrata rimane disponibile solo quando il nuovo kernel la rileva, associa il driver corretto, crea i nodi di rendering e li espone al carico di lavoro.
Dopo un aggiornamento del kernel del server domestico, un’app multimediale può passare all’elaborazione software anche se l’opzione di accelerazione hardware rimane attivata. Il problema può verificarsi durante il rilevamento PCI, l’associazione del modulo del kernel, il caricamento del firmware, la creazione del dispositivo DRM, l’inizializzazione di VA-API, la gestione dei permessi del dispositivo, la mappatura Docker o il percorso FFmpeg del media server. Verifica questi livelli nell’ordine indicato e confrontali con l’avvio precedente prima di modificare le impostazioni dell’applicazione.
Registra il nuovo kernel e conferma la iGPU sul bus PCI
Registra la versione del kernel in esecuzione, i kernel precedenti installati, i parametri di avvio e l’orario dell’aggiornamento. Quindi elenca i dispositivi PCI della classe display con gli ID numerici e il driver del kernel attualmente associato alla GPU integrata.
Se la iGPU è assente dall’enumerazione PCI, controlla le impostazioni del firmware o del BIOS prima di eseguire il debug di VA-API. Un server può esporre solo una GPU discreta quando un’opzione iGPU o multi-monitor è disabilitata, come mostrato nel caso in cui la iGPU era nascosta a Linux.
Confronta l’ID del dispositivo e il driver associato con quelli dell’ultimo avvio sicuramente funzionante. Nei sistemi Intel, di solito si tratta di i915 oppure, nei percorsi più recenti supportati, di xe; usa il driver effettivamente previsto per l’hardware e la distribuzione, invece di forzare il nome di un modulo appartenente a un’altra piattaforma.
Leggi i log del kernel per l’inizializzazione di driver e firmware
Cerca nel log dell’avvio corrente il driver della GPU, DRM, il firmware GuC o HuC, l’inizializzazione del display, gli errori di rilevamento, i timeout e i moduli bloccati. Confronta gli stessi messaggi del kernel precedente, se sono disponibili log persistenti.
Un errore del media driver può verificarsi anche quando l’hardware è elencato. Un problema Intel documenta un errore di inizializzazione VA-API su una GPU Xe-LPG integrata dopo una modifica dello stack software circostante, dimostrando che rilevare l’hardware non è sufficiente.
Conferma che i pacchetti firmware necessari siano ancora presenti e che il modulo non sia bloccato da un nuovo parametro del kernel, da una blacklist o da una policy di avvio sicuro. Non reinstallare il media server finché il driver dell’host non si inizializza correttamente.
Conferma che il nodo di rendering DRM esista ancora
Ispeziona /dev/dri e registra i numeri major e minor, i proprietari, i gruppi e i destinatari dei link simbolici per ogni scheda e nodo di rendering. Non dare per scontato che la iGPU rimanga sempre renderD128 quando è presente un’altra GPU.
L’accelerazione hardware non funziona quando FFmpeg punta a un nodo esistente che però non fornisce più un display VA valido. Un report di Jellyfin mostra l’errore decisivo: nessun display VA per il dispositivo di rendering.
Ricollega il nodo di rendering al dispositivo PCI tramite sysfs, quindi aggiorna la configurazione del container o dell’applicazione solo se l’identità del nodo è effettivamente cambiata. Evita permessi troppo ampi come mode 777; mantieni il modello basato sul gruppo di rendering e verifica l’appartenenza dell’account del servizio.
Testa VA-API o Quick Sync sull’host prima di Docker
Esegui lo strumento diagnostico VA-API della distribuzione sul nodo di rendering verificato e acquisisci il nome del driver, la versione VA-API, i profili di decodifica supportati, i punti di ingresso per la codifica e le funzionalità di elaborazione video.
Il media driver nello spazio utente deve corrispondere alla generazione dell’hardware e all’interfaccia del kernel. Un caso Linux risolto sottolinea che i moduli DRM del kernel e i driver DRI o VA nello spazio utente sono livelli separati; confonderli può lasciare installato il driver dello spazio utente errato.
Se VA-API sull’host non funziona, confronta i pacchetti media driver e firmware correnti con le versioni precedenti all’aggiornamento. Se VA-API sull’host funziona, non modificare kernel e driver mentre passi alla verifica del confine del container.
Verifica lo stesso dispositivo e gli stessi gruppi nel container
Ispeziona i dispositivi del container in esecuzione, gli ID dei gruppi e l’accesso al nodo di rendering scelto. Esegui nel container lo strumento diagnostico VA-API incluso nel media server o la build di FFmpeg, perché il funzionamento sull’host non garantisce quello nel container.
Un container può ricevere /dev/dri/renderD128 e continuare a non funzionare perché il processo non dispone dei permessi corrispondenti del gruppo di rendering. Un report su un container Jellyfin mostra che la mappatura del dispositivo e l’accesso al gruppo devono essere verificati entrambi.
Confronta gli ID numerici dei gruppi sull’host e nel container, quindi ricrea il servizio con una configurazione esplicita del dispositivo e dei gruppi, se necessario. La guida ZimaSpace per controllare la transcodifica hardware fornisce la verifica successiva a livello applicativo.
Forza un test con un codec semplice e osserva i motori GPU effettivi
Usa un campione H.264 o HEVC sicuramente funzionante e forza una transcodifica video senza sottotitoli né conversione dei toni HDR. Registra lo stato della dashboard, il comando FFmpeg, la velocità di transcodifica, l’utilizzo della CPU e l’attività dei motori GPU di decodifica o codifica.
Un media server può segnalare il supporto hardware ma selezionare automaticamente il dispositivo VA-API sbagliato. Un problema di Jellyfin documenta un caso in cui la selezione esplicita del dispositivo ha cambiato il modo in cui FFmpeg rilevava il percorso di accelerazione.
Testa separatamente decodifica e codifica, quando possibile. Se un codec non funziona mentre un codec di base funziona, la iGPU è disponibile, ma quel profilo, quella funzionalità del firmware, quel percorso del driver o quel filtro non sono supportati. Non considerare l’intera GPU assente sulla base di un singolo errore avanzato di conversione dei toni.
Usa il kernel precedente come confronto controllato
Se il rilevamento PCI, i nodi di rendering o VA-API sull’host non funzionano solo con il nuovo kernel, avvia il kernel precedente installato senza modificare l’immagine del container, la versione del media server o la configurazione dello spazio utente.
Un caso di troubleshooting di Jellyfin consiglia di tornare al kernel precedente come discriminante più semplice quando si sospetta che il problema segua una modifica del kernel. Il valore sta nel confronto controllato tra i kernel, non nel considerare il ripristino una soluzione permanente.
La verifica è completa quando il kernel corrente mostra la iGPU sul bus PCI, associa il driver previsto, crea il nodo di rendering corretto, inizializza VA-API, espone il dispositivo nel container e accelera un test reale con un codec. Se supera il test solo il kernel precedente, mantienilo come opzione di avvio temporanea mentre individui la regressione del kernel, del firmware o del media driver.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
