AMD RDNA3/RDNA4 : des performances difficiles sous Linux 6.19, mais les anciennes GPU AMD assurent jusqu’en 2025

AMD voit ses dernières architectures RDNA3 et RDNA4 rencontrer de sévères régressions sur Linux 6.19, provoquant des plantages bloquants. En parallèle, les anciennes cartes graphiques AMD restent stables et offrent un bon niveau de performances avec le pilote AMDGPU jusqu’en 2025.

Linux 6.19 : impact sur la compatibilité et les performances GPU AMD

Le noyau Linux 6.19 a activé par défaut AMDGPU pour plusieurs cartes GCN, entraînant des gains notables sur ces modèles. Cependant, les GPU RDNA3 et RDNA4 subissent des hard hangs systémiques lors de benchmarks lourds.

Les symptômes incluent des systèmes inaccessibles à distance et l’absence de logs kernel écrits sur disque. Ce comportement a été confirmé par des équipes comme Valve et rapporté sur Phoronix.

Méthodologie de test et matériels évalués (fin 2025)

Les essais ont utilisé Linux 6.19 accompagné de Mesa 26.0-devel et des pilotes RADV / RadeonSI / Rusticl. Les bancs incluaient OpenGL, Vulkan, Vulkan compute et OpenCL pour mesurer l’écosystème open source.

Cartes testées : HD 7950, R9 285, R9 290, RX 590, RX Vega 56, RX 5500 XT, RX 5700, RX 5700 XT, RX 6600, RX 6600 XT, RX 6750 XT, RX 6800, RX 6800 XT, RX 7600 XT. Ces modèles ont permis d’isoler la régression sur les architectures récentes.

  • 🛠️ Matériel : tests réalisés sur cartes disponibles en magasin et bancs de test.
  • 📊 Logiciel : Mesa 26.0-devel + RADV/RadeonSI/Rusticl pour cohérence.
  • 🔎 Observations : plantages systématiques sur RDNA3/RDNA4, stabilité sur GCN et RDNA1/2.

Insight : la bascule d’un pilote à l’autre améliore les anciennes cartes mais révèle une régression bloquante sur le matériel récent.

Problème central : plantages bloquants sur RDNA3/RDNA4 sous Linux 6.19

Les plantages se manifestent par des hard hangs complets sans traces de kernel sauvegardées. Ces blocages surviennent rapidement selon la charge GPU, rendant impossible une série complète de benchs.

Ni AMD ni la communauté n’ont fourni de correctif public ou de bissection complète au moment de ces tests. La difficulté tient à la nature « hard hang » qui empêche le bisectage classique sans dispositifs supplémentaires.

Insight : sans instrumentation spécifique, la régression restera difficile à isoler et à corriger rapidement.

Conséquences pour les utilisateurs, développeurs et la communauté open source

Pour les joueurs et professionnels sur Linux, le résultat est clair : éviter les GPU RDNA3/RDNA4 sur Linux 6.18/6.19 jusqu’à résolution. Les machines avec anciennes cartes graphiques restent viables et performantes.

Les mainteneurs open source et les intégrateurs doivent prioriser le diagnostic et la collaboration entre AMD, les développeurs du noyau et les testeurs indépendants. Les rapports publics (Phoronix, forums Valve) servent d’alerte efficace.

Insight : choisir du matériel éprouvé offre une continuité opérationnelle pendant que la communauté travaille sur un correctif.

Recommandations pratiques pour l’action immédiate

Pour l’instant, plusieurs mesures pratiques minimisent le risque : rétrograder le noyau, privilégier les GPU testés stables ou isoler les machines critiques du code lourd GPU. Sauvegarder les logs et préparer un plan de bissection si le temps et le matériel le permettent.

  • ⚠️ Éviter : déployer RDNA3/RDNA4 sur des postes de production sous Linux 6.19.
  • Préférer : RX 500 / RX Vega / RX 5700 et autres modèles listés ci-dessus pour stabilité.
  • 🧰 Actions : collecter dmesg, kmsg et reproduire la charge pour aider au debugging.

Insight : la prudence et la collecte de données précises accélèrent la résolution pour tous.

Ludwig Berthelot

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *