Les firmwares AMD pour GC 11.7 ont rejoint linux-firmware le 21 août. C’est une étape identifiable pour les GPU nommés RDNA 4m dans LLVM, mais pas une annonce commerciale ni un résultat complet de compatibilité.
Lire la fusion composant par composant
La fusion dans linux-firmware introduit les fichiers GC 11.7.0 et 11.7.1, avec des firmwares associés pour PSP, SDMA, VPE et l’affichage. DCN 4.2 DMCUB fait déjà partie des changements ; il ne s’agit pas seulement d’un ajout envisagé pour plus tard.
Ces noms identifient des blocs matériels et leurs firmwares. La table des processeurs de LLVM regroupe GFX11.7 sous RDNA 4m et classe gfx1170, gfx1171 et gfx1172 comme cibles APU. Une cible de compilateur ne constitue pas un nom commercial confirmé, une date de sortie ou une fiche produit. L’association proposée dans l’ancien article dépassait ces preuves.
Trois dépendances, puis une application réelle
Pour une application graphique, disposer des firmwares représente une couche. Le pilote du noyau doit initialiser et gérer le périphérique ; les pilotes graphiques et compilateurs en espace utilisateur doivent prendre en charge les opérations demandées. L’application emprunte ensuite un chemin particulier dans cet ensemble. Mettre une couche à jour n’actualise pas automatiquement les autres.
Il faut distinguer un fichier disponible dans le dépôt amont, son intégration dans les paquets de la distribution et son chargement par le système en fonctionnement. Une distribution peut être en retard ou intégrer des correctifs rétroportés. Cette fusion ne suffit donc pas à garantir toutes les fonctions avec un couple précis de versions du noyau et de Mesa.
Une fiche de validation concrète
Sur le matériel concerné, relevez l’identifiant du périphérique, les versions des paquets et les messages de chargement du firmware avant d’interpréter un échec. Séparez ensuite quatre résultats : affichage, rendu accéléré, veille et reprise, puis codec vidéo nécessaire. Voir le bureau apparaître ne valide pas les quatre.
Prenons un exemple original fictif : un portable affiche le bureau et calcule une scène, mais perd son écran après la veille. Les deux premières observations restent valides ; elles ne transforment pas la troisième en réussite. De même, l’échec d’un codec ne prouve pas l’absence de toute accélération graphique.
Cette méthode décrit une évaluation à réaliser. PeopleAreGeek n’a pas testé de portable RDNA 4m ni installé ces firmwares pour produire des mesures. L’actualité vérifiable porte sur leur livraison dans le dépôt amont ; les autres couches exigent leurs propres preuves.
Revue du 8 septembre : sources et évolutions vérifiées, explications et illustration reprises.