Près de 20 ans après leur sortie, les cartes graphiques ATI Radeon HD 2000 et 3000 reçoivent un correctif vidéo dans Linux 7.5 grâce à l’IA
Lancées entre le printemps 2007 et le début de l’année 2008, les cartes graphiques ATI Radeon HD 2000 et Radeon HD 3000 semblaient figées depuis longtemps dans les musées du silicium. Pourtant, près de vingt ans après leur arrivée dans les boîtiers PC, un correctif inattendu vient d’être validé pour la fenêtre de fusion du futur noyau Linux 7.5. Ce patch résout enfin un bug historique qui corrompait l’affichage lors du décodage vidéo matériel UVD (Unified Video Decoder) sur les puces d’architecture TeraScale 1 (série R600). Plus surprenant encore : cette anomalie vieille de près de deux décennies a été débusquée et corrigée par un nouveau contributeur épaulé par l’intelligence artificielle Codex d’OpenAI.
Un conflit mémoire vieux de 19 ans entre le rendu 3D et le décodeur UVD 1.0
Pour comprendre l’origine de ce dysfonctionnement, il faut remonter à l’introduction du bloc matériel UVD 1.0 en 2007. Conçu à l’époque du rachat d’ATI par AMD pour décharger les processeurs double cœur de la lecture des flux haute définition Blu-ray et HD DVD en H.264 et VC-1, ce moteur dédié souffrait sous Linux d’un défaut particulièrement frustrant : dès que la carte graphique décodait une vidéo tout en exécutant simultanément des appels de rendu 3D ou des opérations de composition du bureau, l’image vidéo se couvrait d’artefacts et de trames corrompues.
C’est en cherchant à comprendre pourquoi son ancien Apple iMac 7,1 de mi-2007 (équipé d’une puce mobile ATI Mobility Radeon HD 2400 XT, nom de code RV610 / M74, identifiant matériel 1002:94c8) produisait ces corruptions visuelles sous Debian que le développeur Ted Bullock a mis le doigt sur le problème. Dans son rapport soumis sur la liste de diffusion officielle du noyau Linux, il détaille le mécanisme exact de la panne : lorsque le décodeur UVD lisait les flux vidéo compressés directement depuis la mémoire vive du système (RAM via l’espace GTT) pendant que le processeur graphique dessinait à l’écran, la contention d’accès mémoire altérait les données du flux vidéo.
Cinq familles de puces RV6xx épinglées en mémoire vidéo dédiée (VRAM)
En inspectant le pilote noyau open source historique drm/radeon avec l’assistance de l’agent de programmation Codex d’OpenAI pour naviguer dans ce code ancien, construire ses tests et formuler le correctif, Ted Bullock a constaté que le pilote appliquait déjà une parade identique pour d’autres générations matérielles. Jusqu’ici, lors de la validation des tampons destinés à l’anneau d’exécution UVD, le pilote forçait uniquement le maintien intégral des flux en mémoire vidéo dédiée (VRAM) pour les cartes connectées en bus AGP ainsi que pour les anciens chipsets intégrés RS780 et RS880, mais laissait les puces PCIe de la famille RV6xx placer leurs tampons d’entrée en mémoire système.
Le patch déplace donc systématiquement les tampons d’entrée UVD vers la VRAM dédiée de la carte graphique, éliminant immédiatement toute corruption d’image même lorsque le GPU est sollicité par le rendu graphique. Parce qu’elles partagent toutes le même chemin de décodage matériel et le même microcode historique R600, cinq familles de puces commercialisées entre 2007 et 2008 bénéficient directement de cette mise à jour :
- RV610 (65 nm) : ATI Radeon HD 2400 Pro, Radeon HD 2400 XT et Mobility Radeon HD 2400.
- RV630 (65 nm) : ATI Radeon HD 2600 Pro, Radeon HD 2600 XT et leurs déclinaisons mobiles.
- RV670 (55 nm) : ATI Radeon HD 3850, Radeon HD 3870 et FireStream 9170.
- RV620 (55 nm) : ATI Radeon HD 3450 et Radeon HD 3470.
- RV635 (55 nm) : ATI Radeon HD 3650 et Mobility Radeon HD 3650.
Pour mémoire, la célèbre Radeon HD 2900 XT équipée de la volumineuse puce R600 originelle en 80 nm ne figure pas dans cette liste pour une raison purement matérielle : contrairement aux déclinaisons RV610 et RV630 sorties quelques semaines plus tard, le fleuron de mai 2007 était dépourvu de bloc matériel UVD et confiait le décodage haute définition à ses 320 unités de calcul vectoriel.
Une intégration officielle dans Linux 7.5 validée par les mainteneurs d’AMD
Bien qu’AMD ait arrêté le support officiel des pilotes propriétaires Windows pour l’architecture TeraScale il y a plus d’une décennie, la pile graphique open source sous Linux continue d’entretenir ce matériel d’époque. Après la prise en charge initiale de l’UVD 1.0 codée par Christian König en 2014 (à l’époque du noyau Linux 3.18), ce nouveau correctif a été validé et intégré par Alex Deucher, mainteneur en chef des pilotes Linux chez AMD, au sein de sa demande de tirage drm-next destinée à Linux 7.5.
Ce futur cycle du noyau s’annonce particulièrement symbolique pour l’histoire de l’informatique PC : alors que Linux 7.5 vient tout juste de purger les dernières optimisations assembleur Intel MMX de 1997, il améliore dans le même temps la fiabilité de cartes graphiques sorties sous l’ère Windows Vista.
De son côté, l’équipe logicielle d’AMD poursuit ses travaux sur les générations futures au sein du pilote moderne amdgpu, où plus de 12 600 lignes de code posent déjà les fondations de la future architecture RDNA 5 (GFX13) à côté des cartes RDNA 4 actuelles.
Voir les disponibilités sur Amazon→
Mon avis sur cette fiche technique
En tant qu’amoureux des vieilles architectures qui ont façonné le PC moderne, revoir les noms de code RV610, RV630 et surtout RV670 apparaître dans un changelog du noyau Linux en 2026 me procure un vrai plaisir de passionné. Ceux qui montaient des PC de salon (HTPC) en 2007 et 2008 s’en souviennent parfaitement : là où la bouillante Radeon HD 2900 XT réclamait une centrale nucléaire et faisait l’impasse sur le bloc UVD, les petites HD 2400 XT, HD 2600 XT puis l’excellente Radeon HD 3870 gravée en 55 nm permettaient enfin de lire un film Blu-ray en 1080p sans mettre à genoux un Athlon 64 X2 ou un Core 2 Duo. Que ces cartes reçoivent encore des correctifs dix-neuf ans après leur mise en rayon montre toute la noblesse du modèle open source face à l’obsolescence programmée des pilotes propriétaires. Nous n’avons pas encore eu ce matériel entre les mains à la rédaction : si le constructeur souhaite nous confier un exemplaire de test pour le passer sur notre protocole complet en conditions réelles, notre banc d’essai lui est grand ouvert.
Et je dois admettre, avec un clin d’œil complice à notre collègue Chaya « Chayane » qui suit de près les avancées des modèles de langage, que la méthode employée ici mérite le coup de chapeau. Un développeur qui n’avait jamais touché à cette couche historique du pilote drm/radeon a pu s’appuyer sur Codex pour isoler en quelques essais un bug de placement mémoire entre RAM système et VRAM qui traînait sous le tapis depuis plus d’une décennie. Utilisée comme un oscilloscope logiciel entre les mains d’un bricoleur curieux sur un vieil iMac de 2007, l’IA prouve qu’elle peut aussi servir à sauver notre patrimoine matériel.
Retrouvez Pro-Gamer en priorité sur Google
Ajoutez pro-gamer.fr à vos sources préférées pour retrouver nos guides et actus directement dans votre flux Google Discover et vos résultats de recherche.
Passionné de hardware et de jeu vidéo, Arthur « Heimdall » navigue entre la France et l'Angleterre où il travaille dans la vente de solutions logicielles B2B. Diplômé d'école de commerce et passionné de bancs d'essai, il monte et démonte des PC depuis son enfance, traquant chaque degré thermique et chaque milliseconde de latence d'affichage. Joueur éclectique passé par Assassin's Creed et Roblox, c'est sur les raids de World of Warcraft qu'il a rencontré Grimtag et Chaya avant de rejoindre l'aventure Pro-Gamer.
