ATI avant AMD : l’autre école de l’ingénierie graphique

Deux écoles d’ingénierie graphique (et pourquoi l’ops devrait s’en soucier)

ATI avant AMD se situe dans cet entre-deux maladroit et peu documenté : pas assez « vintage » pour que les collectionneurs écrivent avec tendresse sur chaque stepping, pas assez « moderne » pour bénéficier des observabilités actuelles et des écosystèmes de pilotes ouverts. Pourtant, les décisions architecturales de cette époque résonnent encore dans les systèmes d’aujourd’hui : hypothèses d’ordonnancement des shaders, décisions d’empaquetage des pilotes, responsabilités du firmware, et l’idée même qu’un GPU n’est pas un périphérique — c’est un petit ordinateur avec un contrat social fragile avec votre OS.

Quand on discute « ATI vs NVIDIA » à cette période, on le fait souvent comme des joueurs : FPS, qualité d’image, une version de pilote qui a ruiné le week-end de quelqu’un. Les personnes en opérations devraient argumenter différemment. Nous devrions demander :

• Comment chaque fournisseur traitait la compatibilité : strict ou tolérant ?
• Où le travail atterrissait : dans le matériel, le microcode ou les pilotes ?
• Comment la pile échouait : blocage, réinitialisation, artefact ou corruption silencieuse ?
• Quelle était l’observabilité : compteurs, logs, codes d’erreur, reproductibilité ?

L’« autre école » d’ATI était souvent un mélange de matériel ambitieux et d’une pile de pilotes qui devait lisser ces différences à travers trop de versions d’OS, révisions d’API et bizarreries de cartes mères. Cela a créé un profil de fiabilité spécifique : impressionnant quand tout est aligné, chaotique dès qu’une petite mauvaise configuration survient.

Sèche mais vraie : si vous exécutez de la visualisation de production, du CAO, du VDI ou des calculs accélérés par GPU sur des flottes mixtes, vous n’avez pas besoin d’un attachement à la marque. Vous avez besoin d’une alphabétisation des modes de défaillance.

Une blague, parce qu’on l’a méritée : les pilotes GPU sont comme les prévisions météo — suffisamment précis pour planifier, mais ne pariez jamais votre release dessus.

Faits historiques concrets que vous pouvez réellement utiliser

Voici des faits courts et opérationnellement pertinents et des points de contexte sur ATI avant AMD. Pas de visite de musée, juste les éléments qui expliquent le comportement en conditions réelles.

1. La gamme Rage d’ATI a précédé Radeon, et l’élan initial de Radeon tenait en partie à la correction de la perception « on peut faire du 3D maintenant, promis » des accélérateurs de la fin des années 90.
2. ATI a acquis ArtX (2000), une équipe avec une forte expérience console (notamment liée au GPU du GameCube de Nintendo). Cette influence s’est manifestée dans la confiance architecturale et les feuilles de route fonctionnelles ultérieures.
3. Radeon 9700 Pro (R300, 2002) fut un tournant : une conception de classe DX9 qui a fait avancer le marché et, important pour l’ops, a augmenté la complexité des pilotes en même temps que le shading programmable.
4. Catalyst est devenu la marque unifiée de pilotes au début des années 2000. L’empaquetage unifié paraît ennuyeux jusqu’à ce que vous essayiez de reproduire un bug sur trois images OS et cinq forks pilotes OEM « aléatoires ».
5. ATI a fortement accompagné la transition AGP → PCIe. Les puces bridge et les interactions avec les chipsets comptaient ; « c’est le même GPU » était souvent un mensonge au niveau du système.
6. L’ère X1000 (milieu des années 2000) misait sur Shader Model 3.0 et un ordonnancement complexe. Super quand ça fonctionnait ; plus difficile à déboguer quand le pilote faisait une mauvaise estimation.
7. L’histoire d’ATI sur Linux a été historiquement plus cahoteuse que sur Windows pendant longtemps, avec des pilotes propriétaires qui semblaient appartenir à un univers distinct de l’évolution du DRM du noyau.
8. ATI a été rachetée par AMD en 2006. Les années pré-AMD reflètent les priorités d’ATI : rapidité d’ajout de fonctionnalité et couverture large des consommateurs, parfois au détriment de frontières d’abstraction propres.

Ce ne sont pas des anecdotes. Elles expliquent pourquoi vous voyez encore certaines classes de problèmes sur des Radeons hérités : comportement de l’aperture AGP, cas limites OpenGL ICD instables, et incompatibilités d’empaquetage de pilotes qui ressemblent à une dérive de configuration — parce qu’elles en sont une, mais avec un GPU.

Ce qu’ATI a construit avant AMD : choix d’architecture qui réapparaissent dans les pannes

La programmabilité a changé le profil des incidents

Les pipelines à fonctions fixes tombaient en panne de façon relativement prévisible. Vous aviez un mauvais blend, des textures manquantes, du z-fighting, ou des plantages sévères avec un ensemble étroit de déclencheurs. Quand le pipeline est devenu programmable — vertex shaders, pixel shaders, et finalement un ordonnancement plus flexible — la surface de défaillance s’est considérablement élargie :

• Les compilateurs côté pilote (compilation et optimisation des shaders) sont devenus partie intégrante de votre runtime.
• Le comportement indéfini et les shaders limites ont cessé d’être « juste plus lents » pour devenir « parfois corrompus ».
• La marge thermique et d’alimentation a pris plus d’importance parce que le matériel pouvait être poussé vers des mixes d’instructions plus complexes.

L’ère pré-AMD d’ATI vivait justement cette transition. Certaines conceptions étaient en avance sur leur temps. D’autres étaient simplement en avance sur leurs pilotes.

AGP et le mythe du « simple bus »

Les systèmes AGP étaient un piège de fiabilité déguisé en amélioration de performance. Le GPU pouvait DMA des textures depuis la mémoire système, et le chipset/BIOS du système avait son avis sur la manière dont cela devait fonctionner. Si vous diagnostiquez une station de travail legacy ou un système industriel avec un Radeon ancien, ne traitez pas la configuration du bus comme une note en bas de page. C’est un suspect de premier plan.

Bridges, variantes et taxe opérationnelle des SKUs

ATI devait livrer sur un marché exigeant un nombre absurde de SKUs : différentes tailles de mémoire, types de mémoire, layouts de cartes et interfaces bus. Le bridging AGP → PCIe (puis son nettoyage) a créé des situations où deux cartes « même modèle » se comportaient différemment sous stress. Du point de vue SRE, c’est le classique problème des « pets qui se prennent pour du bétail » : vous imagez une machine en supposant l’homogénéité ; la carte GPU dit le contraire.

Qualité d’image vs prévisibilité

ATI a historiquement beaucoup soigné la qualité d’image et l’exhaustivité fonctionnelle. Ce n’est pas du marketing ; cela affecte les priorités d’ingénierie. Cela peut signifier des chemins de filtrage plus complexes, davantage de chemins dans le pilote, et un comportement conditionnel selon le profil d’application. Ce n’est pas automatiquement mauvais — mais cela augmente la variance, et la variance est ce qui transforme une régression de performance en incident.

Morale opérationnelle : plus votre pilote est « intelligent », plus vous devez le traiter comme un composant dynamique digne d’un contrôle des changements, d’un verrouillage de version et de plans de rollback.

L’histoire des pilotes : Catalyst, ICDs et le coût de la compatibilité

Catalyst comme objet opérationnel, pas seulement un téléchargement

Catalyst n’était pas qu’un pilote. C’était un bundle : parties en mode noyau, couches API en mode utilisateur, panneaux de contrôle, et heuristiques spécifiques aux applications. ATI pré-AMD a dû supporter un écosystème Windows chaotique (différentes versions de DirectX, service packs, personnalisations OEM) et un écosystème Linux qui cherchait encore à organiser les responsabilités DRM/KMS.

En termes de production, Catalyst ressemblait plus à une « release plateforme » qu’à un simple « pilote de périphérique ». Traitez-le comme tel. Quand vous le mettez à jour, vous mettez à jour un compilateur, un ordonnanceur et un moteur de politiques qui décide comment mapper les appels API vers le matériel.

OpenGL ICDs et le « ça marche sur ma machine »

Sur Windows, OpenGL passe souvent par un Installable Client Driver (ICD). Si vous n’avez jamais débogué un mismatch d’ICD OpenGL, imaginez du linking dynamique plus des réglages du registre plus des fallback spécifiques à l’application, puis ajoutez un panneau de contrôle du fournisseur qui peut écraser les défauts. Quand ça échoue, ça peut basculer sur l’implémentation logicielle de Microsoft ou sur un shim de compatibilité — ce qui signifie que votre GPU est « OK » tandis que la performance s’effondre.

Enseignement opérations : vérifiez que l’application utilise réellement le chemin GPU prévu. Ne supposez pas que parce que le Gestionnaire de périphériques est content, tout va bien.

Timeouts, réinitialisations et l’OS qui se protège

Windows moderne a Timeout Detection and Recovery (TDR). À l’époque pré-AMD d’ATI, l’écosystème convergé vers un comportement de récupération robuste. Un job GPU de longue durée pouvait figer l’UI et prendre toute la machine en otage. Même aujourd’hui, vous voyez la filiation : l’OS réinitialisera le pilote pour garder le système interactif, ce qui est super pour les postes de travail et catastrophique pour le compute headless ou les rendus longs si vous ne le configurez pas.

La fiabilité est souvent l’art d’empêcher des mécanismes de sécurité « utiles » de détruire votre charge tout en préservant le confinement des plantages. Ce n’est pas philosophique ; c’est une clé de registre et une décision de politique.

Une citation, car c’est toujours la meilleure encadrement pour ce travail : Hope is not a strategy. —General Gordon R. Sullivan

Tâches pratiques : commandes, sorties et décisions (12+)

Ci-dessous se trouvent les tâches réelles que je lancerais lors du diagnostic de problèmes GPU ATI/Radeon sur des systèmes Linux (et quelques contrôles hôtes généralement utiles). Chaque entrée inclut la commande, une sortie d’exemple, ce que cela signifie et la décision à prendre.

1) Identifier le GPU et quel pilote est lié

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+4p'
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV770 [Radeon HD 4870] [1002:9440]
	Subsystem: Sapphire Technology Limited Device [174b:e610]
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu

Sens de la sortie : Vous avez un GPU ATI (vendor ID 1002). Le noyau utilise actuellement le pilote radeon, mais amdgpu est aussi présent comme module.

Décision : Si c’est du matériel legacy stable sur radeon, figez-le. Si vous poursuivez des plantages et que le GPU est supporté par amdgpu, envisagez des tests contrôlés avec amdgpu (mais faites-le avec un plan de rollback).

2) Confirmer la largeur et la vitesse du lien PCIe (goulot caché classique)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1
LnkSta: Speed 2.5GT/s (downgraded), Width x4 (downgraded)

Sens de la sortie : La carte peut faire PCIe Gen2 x16, mais fonctionne actuellement en Gen1 x4. Ce n’est pas « un peu plus lent ». C’est un incident auto-infligé.

Décision : Vérifiez les paramètres du BIOS, l’assise de la carte, les risers, la bifurcation de lanes et le choix du slot de la carte mère. Si c’est une flotte, auditez tous les nœuds pour des déclassements de lien.

3) Vérifier les logs du noyau pour réinitialisations/bloquages GPU

cr0x@server:~$ sudo dmesg -T | egrep -i 'radeon|amdgpu|gpu reset|ring|timeout' | tail -n 20
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000a3f1b last fence id 0x00000000000a3f1c on ring 0)
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: ring 0 stalled for more than 10240msec
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: GPU softreset: 0x00000000
[Mon Jan 13 09:41:23 2026] radeon 0000:01:00.0: GPU reset succeeded, trying to resume

Sens de la sortie : Vous avez un vrai blocage GPU et une récupération. Ce n’est pas un bug applicatif tant que l’inverse n’est pas prouvé ; cela peut être de l’alimentation, du thermique, de la VRAM, ou un chemin pilote/firmware.

Décision : Corrélez avec le timing de la charge ; vérifiez les températures ; réduisez les fréquences si overclockées ; testez une version de pilote connue stable ; envisagez un échange de matériel si les réinitialisations persistent.

4) Vérifier quel pilote DRM est chargé et avec quels paramètres

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0 root=UUID=... ro quiet splash radeon.modeset=1

Sens de la sortie : Les paramètres de démarrage du noyau incluent une directive de modeset pour radeon.

Décision : Si vous mélangez des GPUs legacy et des noyaux modernes, définissez explicitement le pilote et le comportement de modeset prévu plutôt que de compter sur l’autodétection.

5) Confirmer les dispositifs DRM et les permissions (piège courant headless/VDI)

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root         80 Jan 13 09:40 by-path
crw-rw---- 1 root video  226,   0 Jan 13 09:40 card0
crw-rw---- 1 root render 226, 128 Jan 13 09:40 renderD128

Sens de la sortie : Les nœuds de périphérique existent ; le nœud render appartient au groupe render. Votre compte de service pourrait ne pas appartenir à render ou video.

Décision : Ajoutez le compte de service au groupe approprié, ou configurez des règles udev. Si vous « réparez » ça avec chmod 666, vous créez un incident de sécurité pour résoudre un incident de performance.

6) Vérifier si Mesa utilise l’accélération matérielle

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: Mesa
OpenGL renderer string: AMD RV770 (DRM 2.50.0 / 6.5.0, LLVM 15.0.7)
OpenGL version string: 3.3 (Core Profile) Mesa 23.2.1

Sens de la sortie : Mesa pilote le GPU via DRM ; vous n’êtes pas tombé en rendu logiciel llvmpipe.

Décision : Si vous voyez llvmpipe ou softpipe, arrêtez le tuning de performance de l’application. Réparez d’abord la sélection du pilote et la pile GL.

7) Détecter immédiatement le rendu logiciel (contrôle rapide)

cr0x@server:~$ glxinfo -B | grep -i renderer
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)

Sens de la sortie : Vous rendez sur le CPU. Votre « problème de performance GPU » est en réalité un problème de « GPU non utilisé ».

Décision : Vérifiez la configuration Xorg, les pilotes Mesa, le passthrough dans les conteneurs, ou le firmware manquant. Ne faites pas de benchmarks tant que cela n’est pas corrigé.

8) Vérifier la visibilité Vulkan (le cas échéant)

cr0x@server:~$ vulkaninfo --summary | sed -n '1,25p'
Vulkan Instance Version: 1.3.268

Devices:
========
GPU0:
	apiVersion         = 1.2.170
	driverVersion      = 0.0.1
	vendorID           = 0x1002
	deviceName         = AMD RADV RV770
	deviceType         = DISCRETE_GPU

Sens de la sortie : Vulkan voit le périphérique et la pile RADV est présente (si supportée pour ce GPU/classe).

Décision : Si les devices Vulkan sont absents mais qu’OpenGL fonctionne, il se peut qu’il manque des paquets ICD Vulkan ou que le matériel ne soit tout simplement pas supporté. Choisissez l’API en conséquence.

9) Vérifier le log Xorg pour fallback pilote et incompatibilités ABI

cr0x@server:~$ egrep -i 'radeon|amdgpu|failed|fallback|ABI|glamor' /var/log/Xorg.0.log | tail -n 20
[     9.231] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[     9.245] (II) RADEON(0): glamor X acceleration enabled on RV770
[     9.246] (WW) RADEON(0): Option "AccelMethod" is not used
[     9.312] (EE) AIGLX: reverting to software rendering

Sens de la sortie : Le DDX s’est chargé, glamor est activé, mais AIGLX est revenu au rendu logiciel. C’est une configuration à mi-accélération — souvent pire que d’être entièrement accéléré ou entièrement logiciel.

Décision : Corrigez le chemin GL/AIGLX (Mesa, permissions, libGL assorties). N’acceptez pas « ça démarre » comme succès.

10) Mesurer la saturation CPU vs attente GPU (division rapide au niveau supérieur)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(32 CPU)

09:52:18 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:52:19 AM  all   22.41  0.00  6.13    0.12 0.00  0.51   0.00   0.00   0.00  70.83

Sens de la sortie : Le CPU n’est pas saturé. Si les images sont lentes, vous êtes peut-être lié au GPU, lié à la synchronisation, ou bloqué dans le pilote.

Décision : Passez aux compteurs/logs côté GPU (réinitialisations, fréquences, VRAM) et au profilage applicatif.

11) Vérifier l’utilisation VRAM et GTT sur Linux (lorsque exposé)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm 2>/dev/null || echo "no amdgpu vram mm stats"
no amdgpu vram mm stats

Sens de la sortie : Vous n’êtes probablement pas sur amdgpu ou le nœud n’expose pas ces stats. Sur radeon legacy, la disposition debugfs diffère.

Décision : Ne perdez pas de temps à chasser des compteurs qui n’existent pas. Basculez vers la télémétrie disponible : dmesg pour les réinitialisations, FPS applicatif et capteurs matériels.

12) Lire les données capteurs GPU (thermiques/power) via lm-sensors

cr0x@server:~$ sensors
radeon-pci-0100
Adapter: PCI adapter
temp1:        +92.0°C  (crit = +105.0°C)

Sens de la sortie : 92°C est assez élevé pour déclencher du throttling ou de l’instabilité sur certaines cartes, selon le refroidissement et la santé des VRM.

Décision : Nettoyez le radiateur, améliorez le flux d’air, réassiez la carte, envisagez une nouvelle pâte thermique. Si c’est une flotte : standardisez les courbes de ventilateur et la pression de châssis. Ne « tunez » pas le logiciel autour d’un matériel cuit.

13) Vérifier les modules noyau chargés et conflits éventuels

cr0x@server:~$ lsmod | egrep 'radeon|amdgpu|drm' | head
radeon               1515520  3
drm_ttm_helper         16384  1 radeon
ttm                   106496  2 radeon,drm_ttm_helper
drm_kms_helper        249856  1 radeon
drm                  622592  6 drm_kms_helper,radeon,drm_ttm_helper,ttm

Sens de la sortie : La pile est cohérente : radeon avec les helpers DRM. Si vous voyez à la fois radeon et amdgpu liés au même périphérique, vous avez un problème de configuration.

Décision : Assurez-vous qu’un seul pilote prévu soit lié. Blacklistez l’autre pilote si nécessaire, mais documentez-le sérieusement.

14) Vérifier les erreurs mémoire et la santé PCIe générale (n’ignorez pas AER)

cr0x@server:~$ sudo journalctl -k | egrep -i 'AER|pcie|error|radeon' | tail -n 20
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0:   device [8086:2942] error status/mask=00000001/00002000

Sens de la sortie : Erreurs PCIe corrigées. « Corrigé » ne veut pas dire « sans conséquence » ; ça signifie que vous consommez de la marge et pouvez voir du throttling ou des retries.

Décision : Reseat la carte, vérifiez les risers/câbles, réduisez la vitesse du lien dans le BIOS comme test, ou changez de slot. Si les erreurs corrélent avec les pics de charge, traitez comme un problème matériel/intégrité signal.

15) Confirmer la pression filesystem et le comportement de swap (problèmes GPU qui sont en réalité des problèmes hôtes)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        58Gi       1.2Gi       1.0Gi       2.8Gi       2.6Gi
Swap:          8.0Gi       7.9Gi       120Mi

Sens de la sortie : Vous swappez beaucoup. Les saccades et les images manquées peuvent venir de la pression mémoire, pas du GPU. Aussi, les timeouts pilote peuvent être déclenchés quand l’hôte ne peut pas alimenter le GPU assez rapidement.

Décision : Corrigez la taille mémoire, réduisez la concurrence, ou ajustez la charge. Ne poursuivez pas une « instabilité GPU » pendant que la machine échange intensivement.

Feuille de route de diagnostic rapide : que vérifier en premier/deuxième/troisième

Voici la feuille de route que je donnerais à un ingénieur d’astreinte à 02:00 quand un nœud de visualisation équipé d’un Radeon est « lent » ou « plante ». Elle est ordonnée pour éliminer rapidement les causes les plus fréquentes.

Première étape : confirmer que le chemin GPU est réel (pas un placebo)

1. L’application utilise-t-elle l’accélération matérielle ? Vérifiez le renderer avec glxinfo -B. Si vous voyez llvmpipe, arrêtez et corrigez cela.
2. Le bon pilote est-il lié ? lspci -nnk. Si le périphérique est sur le mauvais pilote noyau, vous déboguez le mauvais système.
3. Les permissions bloquent-elles les nœuds render ? ls -l /dev/dri. Les services headless tournent souvent sans accès render.

Deuxième étape : vérifier les réinitialisations, les blocages et les problèmes de bus

1. Cherchez les blocages/réinitialisations GPU dans dmesg / journalctl -k. Les réinitialisations signifient instabilité ou bug pilote sous charge.
2. Vérifiez l’état du lien PCIe avec lspci -vv. Les liens dégradés peuvent ressembler à une « régression mystérieuse ».
3. Scannez les erreurs PCIe AER. Les erreurs corrigées sont des signaux d’alerte précoces, pas de bonnes nouvelles.

Troisième étape : isoler thermique, mémoire et dérive de configuration

1. Thermiques : sensors. Si c’est chaud, c’est coupable jusqu’à preuve du contraire.
2. Pression mémoire hôte : free -h, plus usage swap. Le paging crée de faux goulots GPU.
3. Dérive de version : confirmez les versions du noyau/Mesa/pilote entre les nœuds. Si un seul hôte a régressé, traitez comme une dérive de configuration, pas comme de la « randomisation ».

Deuxième blague, parce que c’est le moment où les gens commencent à négocier avec l’univers : si votre lien a négocié x4 au lieu de x16, aucune quantité de « tuning GPU » ne vous aidera — la physique ne fait pas de tickets.

Trois mini-histoires d’entreprise tirées du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’équipe gérait une petite ferme de rendu pour des prises de produit internes. Principalement des stations Linux, chacune avec un Radeon discret. La charge n’était pas exotique : aperçu viewport OpenGL, rendus offscreen et un peu de post-traitement. Un nouveau lot de GPU « identiques » arriva du service achats. Même nom de modèle, même taille de mémoire et — crucialement — même autocollant sur la boîte.

Les nouveaux nœuds étaient 20–30 % plus lents et laissaient parfois passer des images dans l’aperçu interactif. Les gens ont d’abord blâmé la nouvelle image OS, puis Mesa, puis la mise à jour applicative. Le premier indice réel vint d’un ingénieur unique qui arrêta de deviner et exécuta lspci -vv sur les nœuds anciens et nouveaux. Les nouveaux nœuds négociaient la largeur PCIe vers x4 sous charge.

Ce qui s’était passé n’était pas magique. Le nouveau lot de cartes avait un layout et des caractéristiques d’alimentation légèrement différents. Dans un châssis particulier avec un riser particulier, la marge d’intégrité du signal n’était pas suffisante. Le lien PCIe s’est entraîné vers le bas pour rester « stable ». Il n’était pas stable de la manière souhaitée ; il était stable de la manière qui cache le problème jusqu’à ce que vous graphiiez le débit.

La mauvaise hypothèse était « même modèle = même comportement ». En termes d’achats, cette hypothèse fait gagner du temps. En opérations, elle crée une classe de bugs impossibles à reproduire sur la machine de l’ingénieur.

La correction fut ennuyeuse : déplacer ces cartes vers différents slots/risers, figer la vitesse du lien dans le BIOS pour des tests de validation, et mettre à jour la checklist de qualification matérielle pour inclure la vérification de la largeur de lien sous charge soutenue. La correction à long terme fut culturelle : n’acceptez jamais « même SKU » comme substitut à la mesure.

Mini-histoire 2 : L’optimisation qui a mal tourné

Un autre atelier exécutait des sessions VDI accélérées GPU pour des designers. Ils avaient un mix de GPU et une politique stricte : maximiser la densité par hôte. Quelqu’un découvrit que baisser les réglages de qualité dans le panneau de contrôle pilote (et activer un ensemble de bascules « performance ») améliorait les scores de benchmark. Le changement fut déployé largement, parce que cela ressemblait à une capacité gratuite.

En moins d’une semaine, la file de tickets se remplit d’artefacts intermittents : bords scintillants, textures manquantes occasionnelles, et des plantages d’application rares mais violents pendant la rotation du viewport. Rien n’était suffisamment cohérent pour reproduire de façon fiable. Chaque fois qu’un utilisateur partageait son écran, le problème s’arrêtait. Classique.

Le retour de bâton n’était pas mystique non plus. Ces bascules « performance » changeaient les chemins de filtrage et les heuristiques, augmentant la dépendance à une voie rapide plus agressive qui avait un bug de cas limite avec un motif de shader spécifique courant dans un outil CAO. Les scènes de benchmark ne le déclenchaient pas. Les charges réelles si.

La remédiation ne fut pas « tout revertir pour toujours ». Ce fut une gestion contrôlée de la configuration : définir un profil baseline connu bon, puis tester A/B une seule bascule avec des charges représentatives, pas des benchmarks synthétiques. Ils finirent par un profil légèrement moins « rapide » mais notablement plus stable. La densité s’améliora au final parce que la stabilité est de la capacité.

Conclusion : les optimisations qui changent les chemins de code sont des changements de production. Traitez-les avec revue de changement, canaris et rollback, même si elles vivent dans une GUI.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une petite organisation d’ingénierie entretenait un musée de systèmes legacy pour une ligne de fabrication. Certaines stations dépendaient d’anciennes applications OpenGL validées des années auparavant sur du matériel ATI. Étant donné le coût de la recertification de l’équipement, ils n’avaient pas le choix : ils gardaient ce qu’ils avaient, soigneusement.

Ils faisaient une chose que tout le monde se moquait jusqu’à ce qu’elle compte : ils figeaient les versions de pilotes et conservaient une « image dorée » interne avec checksums, plus un petit classeur papier qui cartographiait le modèle GPU de chaque machine, la version du firmware/BIOS et la pile pilote connue bonne. Ils gardaient aussi deux GPU de secours du même lot dans des sachets antistatiques, testés trimestriellement.

Un jour, une station commença à se figer complètement lors d’un changement d’équipe — le pire moment possible. Ils ne commençaient pas par réinstaller l’OS ou mettre à jour les pilotes. Ils ont remplacé le GPU par un spare connu bon, confirmé la stabilité, puis emmené le GPU fautif sur un banc. Au banc, les thermiques étaient limites et il commença à renvoyer des erreurs PCIe corrigées intermittentes sous charge.

Parce qu’ils avaient figé les versions et des pièces de rechange, l’« incident » fut une opération de maintenance de 30 minutes, pas une tempête de reproches de plusieurs jours. La cause racine fut le vieillissement matériel et la dégradation du refroidissement, pas le logiciel. La pratique qui les sauva était terne : inventaire, figer, et validation périodique.

C’est le cœur peu glamour du reliability engineering : réduire le nombre d’inconnues jusqu’à ce que l’inconnue restante soit évidente.

Erreurs courantes : symptômes → cause racine → correction

Voici les modes de défaillance qui reviennent de façon répétée dans les flottes Radeon de l’ère ATI et les environnements graphiques mixtes. Chaque entrée vous dit à quoi cela ressemble, ce qui se passe réellement, et quoi faire.

1) Symptom : « Le GPU est lent après une mise à jour »

Cause racine : Basculage du pilote vers le rendu logiciel (llvmpipe/softpipe), souvent dû à des paquets Mesa manquants, libGL incorrecte, ou des lacunes de passthrough en conteneur.

Correction : Vérifiez avec glxinfo -B. Assurez-vous que les drivers DRI Mesa corrects sont installés, la bonne libGL est utilisée et les permissions sur /dev/dri/renderD* sont cohérentes.

2) Symptom : « Saccades aléatoires toutes les quelques secondes »

Cause racine : Pression mémoire hôte et swap, ou contention CPU qui alimente le GPU.

Correction : Vérifiez free -h et la charge hôte. Réduisez la concurrence, ajoutez de la RAM ou repensez la charge. Le tuning GPU ne corrigera pas le paging.

3) Symptom : « Écran noir occasionnel, puis récupération »

Cause racine : Événements de réinitialisation GPU dus à des blocages — thermique, PSU marginal, erreurs VRAM, ou bugs pilotes déclenchés par certains shaders.

Correction : Inspectez dmesg pour logs de lockup/reset. Vérifiez les thermiques (sensors), retirez tout overclock, validez les rails PSU et testez une combinaison pilote/noyau connue stable.

4) Symptom : « Performance différente entre machines ‘identiques’ »

Cause racine : Le lien PCIe a été négocié vers le bas (x16 → x4) ou fonctionne à une vitesse inférieure à cause du slot, riser, BIOS ou intégrité signal.

Correction : lspci -vv pour LnkSta. Reseat, changez de slot, mettez à jour le BIOS, testez avec une vitesse réduite et standardisez les chemins matériels.

5) Symptom : « Une seule application est cassée ; tout le reste fonctionne »

Cause racine : Heuristiques/profils pilotes spécifiques à l’application, cas limite du compilateur de shader, ou mismatch d’extensions OpenGL.

Correction : Reproduisez avec une scène ou un ensemble de shaders minimal ; testez différentes versions de pilotes ; désactivez les profils applicatifs si possible ; validez les capacités GL/Vulkan et assurez la cohérence des bibliothèques runtime.

6) Symptom : « Des artefacts apparaissent après activation de paramètres ‘performance’ »

Cause racine : Forcer des fast paths ou réduire la précision peut déclencher des bugs de rendu ou des problèmes de shading sensibles à la précision.

Correction : Revenez aux valeurs par défaut connues bonnes. Réintroduisez les changements un par un avec des charges représentatives. Traitez les changements du panneau de contrôle comme des changements de code.

7) Symptom : « Le job headless n’accède pas au GPU »

Cause racine : L’utilisateur de service n’a pas accès à /dev/dri/renderD* ou des hypothèses Xorg/Wayland sont intégrées dans les outils.

Correction : Ajoutez l’utilisateur aux groupes render/video ; vérifiez les nœuds de périphérique ; utilisez les render nodes pour le compute/offscreen quand possible ; évitez la dépendance X fragile.

8) Symptom : « Gel intermittent sous forte charge ; les logs montrent des erreurs PCIe »

Cause racine : Problèmes d’intégrité du signal : riser, poussière, oxydation, slot de carte mère faible, ou carte défaillante.

Correction : Reseat, changez de slot, retirez les risers, améliorez le refroidissement et, si AER persiste, remplacez le matériel suspect. Les erreurs corrigées ne sont pas une caractéristique de performance.

Listes de contrôle / plan étape par étape

Checklist A : Mise en service sécurisée d’un nœud ATI/Radeon legacy

1. Inventoriez l’ID exact du GPU et du sous-système (lspci -nn). Enregistrez-le. Ne vous fiez pas aux noms marketing.
2. Choisissez le pilote intentionnellement (radeon vs amdgpu quand applicable). Documentez le choix et figez les versions.
3. Validez la santé du bus : vérifiez LnkSta PCIe et les logs AER.
4. Validez le chemin de rendu : assurez-vous que glxinfo -B montre le renderer matériel, pas llvmpipe.
5. Établissez une ligne de base thermique : enregistrez températures au repos et en charge (sensors).
6. Exécutez un test de charge soutenue suffisamment long pour provoquer un soak thermique (pas seulement un benchmark de 30 secondes).
7. Capturez les versions connues bonnes : noyau, Mesa, Xorg/Wayland, paquets firmware et tout composant propriétaire.
8. Créez un plan de rollback : image snapshot ou verrouillage de paquets. Entraînez-vous au rollback une fois.

Checklist B : Quand un nœud régresse après une mise à jour

1. Confirmez que ce n’est pas du rendu logiciel (glxinfo -B).
2. Vérifiez dmesg/journal pour des réinitialisations (journalctl -k).
3. Comparez l’état du lien PCIe (lspci -vv) par rapport à un nœud sain.
4. Comparez les versions de paquets (pile pilote et Mesa). Ne faites pas confiance à l’œil ; diffez les versions réelles.
5. Vérifiez la pression mémoire hôte (free -h, usage swap).
6. Rollbackez une dimension à la fois : pilote d’abord, puis noyau, puis Mesa/X. Évitez le « j’essaie n’importe quoi ».
7. Notez la charge déclenchante qui montre la régression. Si vous ne pouvez pas reproduire, vous ne pouvez pas corriger.

Checklist C : Faire des changements de pilote sans se faire d’ennemis

1. Canarisez sur un nœud avec des charges réelles, pas seulement des benchmarks.
2. Mesurez trois choses : performance, stabilité (réinitialisations/blocages) et exactitude (artefacts/problèmes de précision).
3. Conservez un jeu d’artefacts connu bon : captures d’écran ou rendus déterministes pour comparaison.
4. Planifiez une fenêtre de rollback et assurez-vous de pouvoir revenir rapidement sans réimage manuelle.
5. Ne mélangez pas les changements : évitez de mettre à jour noyau + Mesa + contrôles pilote en même temps.

FAQ

1) Est-ce qu’ATI était « pire » que NVIDIA avant AMD ?

Pas catégoriquement. ATI a souvent livré du matériel ambitieux puis payé le coût d’intégration en pilotes et compatibilité. NVIDIA penchait souvent plus vers un comportement pilote consistant. Pour l’ops, ce n’est pas « pire », c’est des modes de défaillance différents.

2) Pourquoi les systèmes ATI legacy montrent-ils une variabilité étrange entre machines ?

Parce que le GPU n’est qu’une variable. Chipset, BIOS, entraînement PCIe, risers, alimentation et refroidissement peuvent changer le comportement. De plus, les forks de pilotes OEM étaient courants ; la dérive des versions est réelle.

3) Quel est le contrôle le plus rapide quand la performance chute ?

Vérifiez que vous n’êtes pas en rendu logiciel. Sur Linux, glxinfo -B et regardez la chaîne renderer. Si elle indique llvmpipe, votre GPU n’est pas le goulot — c’est le CPU qui fait le rendu.

4) Pourquoi la largeur du lien PCIe compte-t-elle tant ?

Parce qu’elle régule la soumission de commandes, les uploads de ressources et les readbacks. Un GPU affamé par un lien dégradé se comporte comme un GPU plus lent, sauf que vous ne pouvez pas le corriger avec des réglages. Vous le corrigez par discipline matérielle/BIOs.

5) Les réinitialisations GPU sont-elles toujours un bug pilote ?

Non. Elles sont souvent une marge matérielle : thermiques, instabilité PSU, VRAM vieillissante ou intégrité du signal. Commencez par les logs, puis les thermiques et la santé PCIe. Si vous pouvez reproduire des réinitialisations sur différentes images OS, c’est probablement matériel.

6) Pourquoi l’écosystème de pilotes d’ATI semblait-il compliqué ?

Parce qu’il devait gérer plusieurs APIs, versions d’OS et comportements applicatifs à une époque où les pipelines programmables évoluaient rapidement. La complexité n’était pas optionnelle ; c’était le prix de la compétition sur les fonctionnalités.

7) Pour des nœuds Radeon legacy, dois-je mettre à jour les pilotes ou les figer pour toujours ?

Figez par défaut, mettez à jour délibérément. Si le nœud existe pour exécuter une charge validée, la stabilité prime sur la nouveauté. Si la sécurité et le support OS exigent des mises à jour, traitez-les comme des upgrades de plateforme avec canaris et rollback.

8) Pourquoi les bascules « performance » causent-elles parfois des artefacts ?

Parce qu’elles peuvent changer la précision, les chemins de filtrage ou les heuristiques du compilateur. Si votre charge est sensible à la précision (CAO, visualisation scientifique), ces raccourcis peuvent devenir des bugs de correction.

9) Quelle est une manière fiable de séparer les problèmes liés au GPU de ceux liés au CPU ?

Commencez par mpstat et les métriques hôtes de base : si le CPU est saturé ou swappe, vous êtes probablement lié au CPU/hôte. Si l’hôte est correct et que vous voyez des réinitialisations GPU ou une faible largeur de lien, c’est lié au chemin GPU.

10) Est-ce que tout cela importe maintenant qu’AMD possède ATI ?

Oui, parce que les systèmes legacy persistent et que les schémas d’ingénierie persistent. Aussi, la leçon opérationnelle est intemporelle : les GPU sont des écosystèmes, pas des pièces.

Prochaines étapes que vous pouvez entreprendre cette semaine

• Auditez votre flotte pour le rendu logiciel : vérifiez aléatoirement les chaînes renderer de glxinfo -B sur des nœuds représentatifs.
• Exécutez un audit santé lien PCIe : enregistrez la largeur/vitesse LnkSta sur tous les nœuds GPU et signalez les déclassements.
• Mettez en place une baseline pilote « connue bonne » par génération matérielle et figez-la. Rendez les rollbacks peu coûteux.
• Collectez des preuves de réinitialisation : centralisez les logs noyau et alertez sur les patterns de lockup/reset GPU.
• Standardisez le refroidissement et la propreté : un GPU à 92°C est un bug de fiabilité, pas une ambiance.
• Codifiez le contrôle des changements pour les réglages pilotes : les bascules GUI sont des changements de production. Traitez-les comme tels.

ATI avant AMD rappelle que l’ingénierie graphique ne se résume pas au débit ; il s’agit de la quantité d’imprévisibilité que vous pouvez tolérer. Si vous voulez moins d’incidents, réduisez la variance : figez les versions, vérifiez la santé du bus, surveillez les thermiques et ne supposez jamais que le GPU fait ce que vous pensez qu’il fait.