Comment vérifier qu’un processeur graphique intégré est toujours disponible après une mise à jour du noyau

Un processeur graphique intégré reste disponible uniquement lorsque le nouveau noyau le détecte, associe le pilote approprié, crée les nœuds de rendu et les rend accessibles à la charge de travail.

Après une mise à jour du noyau d’un serveur domestique, une application multimédia peut revenir au traitement logiciel même si son option d’accélération matérielle reste activée. La défaillance peut se produire lors de la détection PCI, de l’association du module du noyau, du chargement du micrologiciel, de la création du périphérique DRM, de l’initialisation de VA-API, de la gestion des permissions du périphérique, de son mappage dans Docker ou du chemin FFmpeg du serveur multimédia. Vérifiez ces couches dans l’ordre et comparez-les avec le démarrage précédent avant de modifier les paramètres de l’application.

Notez le nouveau noyau et confirmez la présence de l’iGPU sur le bus PCI

Notez la version du noyau en cours d’exécution, les anciens noyaux installés, les paramètres de démarrage et l’heure de la mise à jour. Listez ensuite les périphériques PCI de classe affichage avec leurs identifiants numériques ainsi que le pilote du noyau actuellement associé au processeur graphique intégré.

Si l’iGPU est absent de l’énumération PCI, vérifiez les paramètres du micrologiciel ou du BIOS avant de rechercher un problème lié à VA-API. Un serveur peut n’exposer qu’un GPU dédié lorsqu’une option iGPU ou multi-écrans est désactivée, comme dans ce cas où l’iGPU était masqué sous Linux.

Comparez l’identifiant du périphérique et le pilote associé avec ceux du dernier démarrage fonctionnel. Sur les systèmes Intel, il s’agit généralement de i915 ou, pour les chemins plus récents pris en charge, de xe ; utilisez le pilote réellement prévu pour le matériel et la distribution au lieu de forcer le nom d’un module provenant d’une autre plateforme.

Lisez les journaux du noyau concernant l’initialisation du pilote et du micrologiciel

Recherchez dans le journal du démarrage actuel le pilote du GPU, DRM, le micrologiciel GuC ou HuC, l’initialisation de l’affichage, les échecs de détection, les délais d’attente et les listes noires de modules. Comparez les mêmes messages avec ceux de l’ancien noyau si des journaux persistants sont disponibles.

Un échec du pilote multimédia peut se produire même lorsque le matériel est répertorié. Un problème Intel documente l’échec de l’initialisation de VA-API sur un GPU intégré Xe-LPG après une modification de la pile logicielle environnante, montrant que la détection du matériel ne suffit pas.

Vérifiez que les paquets de micrologiciel requis sont toujours présents et que le module n’est pas bloqué par un nouveau paramètre du noyau, une liste noire ou une politique de démarrage sécurisé. Ne réinstallez pas le serveur multimédia tant que le pilote hôte ne s’initialise pas correctement.

Confirmez que le nœud de rendu DRM existe toujours

Inspectez /dev/dri et notez les numéros majeur et mineur, les propriétaires, les groupes et les cibles des liens symboliques pour chaque carte et nœud de rendu. Ne supposez pas que l’iGPU restera toujours renderD128 lorsqu’un autre GPU est présent.

L’accélération matérielle échoue lorsque FFmpeg cible un nœud qui existe, mais ne fournit plus un affichage VA valide. Un rapport Jellyfin présente l’erreur déterminante : aucun affichage VA pour le périphérique de rendu.

Reliez le nœud de rendu à son périphérique PCI via sysfs, puis ne mettez à jour la configuration du conteneur ou de l’application que si l’identité du nœud a réellement changé. Évitez les permissions trop larges telles que le mode 777 ; conservez le modèle fondé sur le groupe de rendu et vérifiez l’appartenance du compte de service.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testez VA-API ou Quick Sync sur l’hôte avant Docker

Exécutez l’outil de diagnostic VA-API de la distribution sur le nœud de rendu vérifié et relevez le nom du pilote, la version de VA-API, les profils de décodage pris en charge, les points d’entrée d’encodage et les capacités de traitement vidéo.

Le pilote multimédia de l’espace utilisateur doit correspondre à la génération du matériel et à l’interface du noyau. Un cas Linux résolu souligne que les modules DRM du noyau et les pilotes DRI ou VA de l’espace utilisateur sont des couches distinctes ; les confondre peut laisser le mauvais pilote de l’espace utilisateur en place.

Si VA-API échoue sur l’hôte, comparez les paquets actuels du pilote multimédia et du micrologiciel avec leurs versions antérieures à la mise à jour. Si VA-API fonctionne sur l’hôte, ne modifiez ni le noyau ni le pilote pendant l’examen de la limite du conteneur.

Vérifiez le même périphérique et les mêmes groupes dans le conteneur

Inspectez les périphériques, les identifiants de groupe et l’accès au nœud de rendu sélectionné dans le conteneur en cours d’exécution. Exécutez l’outil de diagnostic VA-API ou la version de FFmpeg fournie avec le serveur multimédia dans le conteneur, car la réussite sur l’hôte ne garantit pas celle du conteneur.

Un conteneur peut recevoir /dev/dri/renderD128 et échouer malgré tout parce que son processus ne dispose pas de la permission correspondante du groupe de rendu. Un rapport concernant un conteneur Jellyfin montre que le mappage du périphérique et l’accès au groupe doivent tous deux être vérifiés.

Comparez les identifiants numériques des groupes sur l’hôte et dans le conteneur, puis recréez le service avec une configuration explicite du périphérique et des groupes si nécessaire. Le guide ZimaSpace consacré à la vérification du transcodage matériel fournit l’étape de confirmation suivante au niveau de l’application.

Forcez un test simple de codec et observez les moteurs réels du GPU

Utilisez un échantillon H.264 ou HEVC connu comme fonctionnel et forcez un transcodage vidéo sans sous-titres ni conversion de tonalité HDR. Notez l’état du tableau de bord, la commande FFmpeg, la vitesse de transcodage, l’utilisation du processeur et l’activité des moteurs de décodage ou d’encodage du GPU.

Un serveur multimédia peut signaler la prise en charge matérielle, mais sélectionner automatiquement le mauvais périphérique VA-API. Un problème Jellyfin documente un cas où la sélection explicite du périphérique a modifié la détection du chemin d’accélération par FFmpeg.

Testez séparément le décodage et l’encodage lorsque cela est possible. Si un codec échoue alors qu’un codec de base fonctionne, l’iGPU est disponible, mais ce profil, cette fonctionnalité du micrologiciel, ce chemin du pilote ou ce filtre n’est pas pris en charge. Ne concluez pas à l’absence de l’ensemble du GPU à partir d’un seul échec avancé de conversion de tonalité.

Utilisez l’ancien noyau comme comparaison contrôlée

Si la détection PCI, les nœuds de rendu ou VA-API sur l’hôte échouent uniquement avec le nouveau noyau, démarrez sur l’ancien noyau installé sans modifier l’image du conteneur, la version du serveur multimédia ni la configuration de l’espace utilisateur.

Un cas de dépannage Jellyfin recommande de revenir au noyau précédent comme moyen le plus simple de déterminer si l’échec suit une modification du noyau. L’intérêt réside dans une comparaison contrôlée des noyaux, et non dans le fait de considérer le retour en arrière comme une solution permanente.

La vérification est terminée lorsque le noyau actuel affiche l’iGPU sur le bus PCI, associe le pilote prévu, crée le nœud de rendu approprié, initialise VA-API, expose le périphérique dans le conteneur et accélère un test réel de codec. Si seul l’ancien noyau fonctionne, conservez-le temporairement comme option de démarrage tandis que vous isolez la régression du noyau, du micrologiciel ou du pilote multimédia.