Les géants 2D perdus : Matrox, S3, Tseng — et pourquoi ils comptaient

Ce que signifiait réellement « accélération 2D » (et ce que ça vous apportait)

Avant que chaque interface utilisateur ne devienne une scène compositée, le « bureau » était principalement des rectangles. Des rectangles remplis de pixels. Des rectangles copiés d’un endroit à un autre. Des rectangles avec des glyphes de texte estampés.
Si vous pouviez effectuer ces opérations rapidement — et de manière cohérente — vous étiez gagnant. C’est ça, l’accélération 2D : déléguer les primitives ennuyeuses du CPU vers du matériel dédié capable de pousser des pixels
sans négocier avec les caches, les prédicteurs de branchement ou tout ce que le CPU regrettait déjà.

Les primitives clés n’étaient pas glamour :

• BitBLT (bit‑block transfer) : copier un rectangle de pixels de la source à la destination, souvent avec des opérations raster (ROPs).
• Remplissages pleins et motifs : peindre des rectangles rapidement (fonds de fenêtre, surlignages de sélection, chrome UI).
• Tracés de lignes et contours de rectangles : l’ossature des premiers widgets d’interface.
• Curseur matériel : une petite couche superposée pour que le pointeur reste fluide même lorsque le reste de l’écran est occupé.
• Voies d’accélération du texte : glyphes en cache et expansion mono→couleur pour les polices.

En langage opérationnel : ces primitives étaient le « chemin chaud ». Si vous les maîtrisiez, tout paraissait réactif : déplacements de fenêtres, défilement, saisie, sessions d’administration à distance, et
« j’ai ouvert un tableur et mon portable n’a pas donné l’impression de vouloir décoller ».

Aujourd’hui, même si votre interface est composée via un GPU, les mêmes contraintes de base s’appliquent toujours : bande passante mémoire, stalls de pipeline et comportement des pilotes sous charges étranges. Nous avons juste renommé les modes de défaillance.

Une idée paraphrasée que je garde sur mon tableau mental vient de Werner Vogels : tout échoue, concevez pour l’échec plutôt que de prétendre qu’il n’arrivera pas (idée paraphrasée).
Les géants 2D l’ont intégré. Ils ont conçu des cartes et des pilotes qui toléraient des bureaux réels et désordonnés.

Pourquoi Matrox, S3 et Tseng sont devenus la référence 2D

Matrox : sortie nette, ingénierie disciplinée et réputation du « ça marche tout simplement »

Matrox a conquis les utilisateurs soucieux de qualité d’image et de stabilité : utilisateurs CAO, édition, traders regardant plusieurs écrans, et équipes IT qui devaient faire en sorte que tout se comporte.
Leurs moteurs 2D n’étaient pas seulement rapides ; ils étaient prévisibles. Quand vous déployez des centaines ou des milliers de postes, la prévisibilité est une forme de performance.

Matrox considérait aussi l’intégrité du signal comme importante. Parce que c’était le cas. Le VGA analogique n’était pas « bon » par défaut ; il était bon quand le routage de la carte, la qualité du DAC et le filtrage n’étaient pas une réflexion après coup.
Voilà pourquoi on se souvient de Matrox comme « net ». Ce n’était pas une illusion.

S3 : l’empire discret à l’intérieur de chaque boîtier beige

S3 n’a pas toujours été le sujet de vantardise des passionnés. S3 était l’ami des OEM : 2D compétent, large compatibilité, faible coût, et pilotes qui — la plupart du temps — ne généraient pas de tickets de support.
Si vous utilisiez un PC des années 90 au bureau, il y a de fortes chances que S3 ait poussé vos pixels.

Leur succès n’était pas accidentel. Ils ont optimisé pour l’économie de volume et la compatibilité logicielle large. Ce n’est pas glamour, mais ça scale.

Tseng Labs : le bolide du DOS et des débuts de Windows

Tseng est un nom qui fait sourire les vétérans parce que la série ET4000 avait une réputation : elle était rapide. Surtout en DOS VGA/SVGA où le débit brut et les chemins de code serrés comptaient.
La force de Tseng était d’extraire les performances du bus et du sous‑système mémoire d’une manière perceptible dans les charges réelles.

Tseng illustre aussi une leçon récurrente : être le meilleur sur le goulot d’une époque ne garantit pas de survivre au changement de plateforme de l’ère suivante. On en reparle plus loin.

Petite blague #1 : L’ET4000 était si rapide en DOS que certains jeux ont probablement voulu déposer une plainte au service du personnel.

Faits historiques concrets qui expliquent l’engouement

La nostalgie autour de ces fournisseurs n’est pas simplement « le vieux matériel était meilleur ». Elle s’ancre dans des réalités techniques et de marché précises. Voici des points concrets qui comptent vraiment :

1. Windows 3.x et les débuts de Windows 95 s’appuyaient fortement sur l’accélération 2D via des pilotes qui déchargeaient les opérations GDI comme les blits et les remplissages vers la carte.
2. Les VESA BIOS Extensions (VBE) ont standardisé les résolutions SVGA plus élevées pour le logiciel de l’ère DOS, mais la qualité d’implémentation variait selon les cartes.
3. La gamme ET4000 de Tseng est devenue célèbre pour son débit SVGA élevé à une époque où l’efficacité du bus et le timing mémoire importaient souvent plus que les « fonctionnalités ».
4. La famille Trio de S3 a intégré RAMDAC et d’autres fonctions pour réduire le coût et la complexité de la carte — parfait pour le déploiement OEM de masse.
5. Les cartes Matrox de l’ère Millennium ont été largement saluées pour la qualité de sortie analogique quand les CRT rendaient le bruit de signal douloureusement visible (scintillement du texte, saignement des couleurs, bords flous).
6. Les moteurs 2D prenaient en charge un large ensemble d’opérations raster (ROPs) parce que les frameworks UI en dépendaient pour des effets ressemblant à la composition avant que la vraie composition existe.
7. Les curseurs matériels comptaient plus qu’on ne l’admet : garder le pointeur fluide masquait beaucoup de lenteur perçue et réduisait la latence ressentie.
8. Les transitions PCI vs ISA/VLB ont remodelé les gagnants et les perdants parce que le goulot est passé du cœur GPU au bus mastering et au comportement de la bande passante mémoire.
9. Les configurations multi‑écrans précoces étaient de niche et fragiles ; les fournisseurs capables de les gérer de façon fiable (ou au moins avec des pilotes sains) gagnaient la fidélité des utilisateurs à forte valeur.

Remarquez ce qui manque : le ray tracing. Personne n’en avait besoin. Ils voulaient qu’Excel défile sans ressembler à un flipbook.

L’ingénierie pas glamour : bande passante, blits, curseurs et polices

Le 2D, c’est surtout de la bande passante mémoire et du comportement du bus

Une opération 2D typique est un problème de mouvement mémoire. Copiez ce rectangle. Remplissez ce rectangle. Développez des glyphes monochromes en pixels colorés.
Le facteur limitant est souvent la vitesse à laquelle vous pouvez lire et écrire la mémoire du framebuffer et l’efficacité de l’accès via le bus système.

C’est pourquoi un CPU « plus rapide » ne résolvait pas toujours un bureau lent : la charge n’était pas du calcul CPU. C’était du brassage de pixels. Si le GPU pouvait le faire en interne et éviter les allers‑retours sur le bus, vous gagniez.
S’il devait tamponner dans la mémoire système ou attendre l’arbitrage du bus, vous perdiez.

Les pilotes représentaient la moitié du produit

À l’époque du 2D, un pilote était essentiellement une promesse : « Quand l’OS demande un BitBLT avec ce ROP, je ne vais pas maculer l’écran, fuir des handles ou bloquer le thread UI. »
Certains fournisseurs étaient simplement meilleurs pour tenir cette promesse face à des comportements d’applications étranges et des uptimes longs.

Aujourd’hui on dit « le pilote a planté ». À l’époque, vous aviez différentes saveurs de douleur : régions de redraw corrompues, rectangles fantômes, polices rendues comme des hiéroglyphes, et un utilisateur persuadé que son écran est hanté. La cause racine restait la correction logicielle sous charge.

Curseur matériel : petite fonctionnalité, énorme bénéfice opérationnel

Un curseur matériel est une petite image superposée que la carte peut dessiner indépendamment du framebuffer. Le curseur reste réactif même si le moteur de dessin principal est occupé.
Lorsqu’il manque — ou lorsque le pilote retombe sur un curseur logiciel — tout le système « semble lent » parce que le mouvement du pointeur est votre boucle de rétroaction principale.

Le rendu des polices était une fonctionnalité de performance

Les bureaux ne benchmarkent pas des triangles. Ils rendent des polices. Beaucoup. La mise en cache des glyphes et l’accélération de l’expansion mono→couleur rendaient les premiers GUI réactifs.
Et c’est là que la « sortie stable » comptait : un seul bug dans le cache de glyphes pouvait rendre une application illisible et générer une semaine de tickets.

Petite blague #2 : Les curseurs logiciels sont comme des réunions ininterrompues — tout le reste s’arrête pour que vous puissiez regarder un petit élément dériver à l’écran.

Pourquoi ils ont disparu (et pourquoi ce n’est pas « un échec »)

Les géants 2D n’ont pas disparu parce qu’ils avaient oublié comment dessiner des rectangles. Ils ont décliné parce que le marché a changé sa définition de « suffisant » et que le bassin de profits s’est déplacé.
Une fois que le 3D est devenu la fonctionnalité qui vendait des PC — et qu’une intégration graphique était « correcte » en 2D — l’avantage compétitif a changé de camp.

Quelques forces ont fait le travail :

• APIs 3D et demande gaming : les consommateurs achetaient des FPS plutôt qu’une sortie VGA propre.
• Consolidation OEM : les deals de volume favorisaient les fournisseurs avec chipsets intégrés et relations plateformes serrées.
• La complexité des pilotes a explosé : composition, décodage vidéo, gestion d’énergie et hotplug multi‑affichage ont multiplié les modes de défaillance.
• Le 2D « suffisamment bon » est devenu invisible : quand tout est composité, on cesse de remarquer l’excellence 2D jusqu’à ce qu’elle disparaisse.

Matrox s’est orienté vers des niches (multi‑affichage, embarqué, industriel). La marque S3 a survécu sous d’autres formes. Tseng n’a pas survécu à la course 3D de la fin des années 90.
Ce n’est pas un échec moral ; ce sont les lois brutales des transitions de plateforme.

La leçon réelle pour les ingénieurs modernes : les forces de votre produit doivent correspondre au prochain goulot du marché, pas à celui du présent.
Les « rois du 2D » ont résolu le goulot de leur époque avec discipline. Cette discipline vaut encore la peine d’être copiée.

Trois mini‑histoires d’entreprise venues du terrain

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a renouvelé une flotte de stations de travail pour opérations back‑office : écrans ERP, sessions RDP et une application Java interne qui redessinait agressivement.
Les achats ont standardisé sur une plateforme GPU intégrée moderne. Sur le papier, c’était un sans faute : beaucoup de compute, codecs modernes et « évidemment » mieux qu’une carte discrète vieille d’une décennie.

En une semaine, la file de tickets s’est remplie d’une plainte étrange : « La souris colle. » Pas lente. Collante. Les opérateurs déclaraient qu’ils ne pouvaient pas cliquer de façon fiable de petits éléments UI.
Pendant ce temps, l’utilisation CPU était faible et la RAM abondante. L’IT a d’abord blâmé l’application Java, parce que c’est ce qu’on fait quand on veut que le problème disparaisse.

La fausse hypothèse était que le GPU intégré fonctionnerait toujours avec les voies d’accélération appropriées activées. En réalité, l’image avait été déployée avec un paquet de pilotes conservateur.
Sous certains EDID de moniteur et stations d’accueil, la pile est retombée en mode compatibilité qui désactivait le curseur matériel et forçait le rendu logiciel pour certaines parties de l’UI.

La correction n’a pas été héroïque : valider que le bon pilote était installé, confirmer que DRI et modesetting étaient actifs, et standardiser le firmware du dock.
L’important était culturel : ils ont mis à jour la checklist de déploiement pour inclure les combinaisons de périphériques (dock + moniteur) comme cas de test de première classe.

La leçon opérationnelle : n’assumez pas qu’un « GPU plus récent » équivaut à une « meilleure expérience 2D ». En production, la pile est le produit : firmware, pilote, compositeur, protocole distant et moniteurs.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation gérait un environnement VDI où des clients légers affichaient des bureaux Windows via un protocole distant. Quelqu’un a remarqué qu’activer un certain réglage « effets visuels » dans le modèle VDI
réduisait la charge CPU moyenne sur l’hôte. Les graphiques étaient convaincants. Changement approuvé.

Deux semaines plus tard, le helpdesk a commencé à entendre parler de « texte aléatoirement flou » et de « défilement qui se transforme en bouillie ».
Le problème n’était pas constant ; il survenait aux heures de pointe et principalement chez les utilisateurs multi‑écrans. Les graphiques CPU restaient bons, ce qui rendait le problème encore plus irritant.

L’optimisation poussait plus de travail dans une voie graphique qui utilisait une mise en cache bitmap agressive et une compression lossy sous congestion. Quand la bande passante se resserrait,
le protocole s’adaptait en dégradant la qualité. Les utilisateurs l’ont vécu comme du « texte cassé ». La supervision voyait « CPU stable ».

Revenir en arrière sur le réglage a rétabli la lisibilité cohérente au prix d’un CPU hôte plus élevé. Puis ils ont fait le mouvement adulte :
créer une pool dédiée pour les utilisateurs multi‑écrans lourds avec des paramètres de protocole et des garanties QoS différentes.

La leçon : des optimisations qui améliorent un indicateur peuvent détruire le travail réel de l’utilisateur. Si vos « victoires » obligent les utilisateurs à ne plus lire le texte, vous n’avez pas gagné.

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

Une équipe financière gérait des postes de trading avec plusieurs écrans par utilisateur. Ils avaient déjà été brûlés par des « mises à jour rapides de pilotes », donc leur équipe endpoint maintenait une politique conservatrice :
versions de pilotes graphiques épinglées, tests préalables avec leurs modèles de moniteurs exacts, et déploiements en anneaux avec scripts de rollback prêts.

Un matin, un fournisseur a publié une mise à jour système routinière qui mettait aussi à jour un composant graphique. Quelques machines pilotes l’ont installée pendant la nuit.
À 9h05, les pilotes ont signalé un problème subtil mais mortel : les fenêtres repaintaient parfois en noir pendant une fraction de seconde lors de basculements rapides.
Pas de crash. Juste assez pour que les opérateurs doutent de ce qu’ils voyaient.

Parce que l’équipe avait un déploiement en anneaux, ils ont arrêté le rollout avant qu’il n’atteigne tout le parc. Parce qu’ils avaient épinglé les versions, le rollback était déterministe.
Parce qu’ils disposaient d’une capture de référence du comportement sain, ils ont pu prouver la régression rapidement sans se prendre la tête dans des débats subjectifs.

Rien de héroïque n’est arrivé. C’est bien le propos. La pratique ennuyeuse a empêché un incident impactant le business sans créer un incident plus grand via des expérimentations frénétiques.

Mode d’emploi rapide : quoi vérifier en premier/deuxième/troisième

Quand quelqu’un dit « le bureau est lent », il faut une approche disciplinée. Ne poursuivez pas des impressions flottantes. Trouvez le goulot.

Premier : s’agit‑il d’un rendu local, distant, ou style DisplayLink via USB ?

• Si c’est distant (RDP/VDI), le goulot peut être la bande passante, l’encodage, la composition côté serveur ou le décodage client.
• Si c’est du graphisme USB/dock, vous pouvez être CPU‑bound sur la compression et le transport.
• Si c’est local, passez aux vérifications GPU/pilote/compositeur.

Deuxième : utilisons‑nous réellement l’accélération matérielle ?

• Confirmez le driver noyau en usage (modesetting/i915/amdgpu/nouveau/nvidia, etc.).
• Confirmez que DRI est actif et que le renderer n’est pas « llvmpipe » (software).
• Vérifiez si le curseur matériel est activé ; le saccadement du curseur est un indice.

Troisième : le système est‑il à court (CPU, mémoire, I/O), ou est‑ce spécifique au chemin graphique ?

• Un CPU élevé durant le défilement signifie souvent rendu logiciel ou overhead d’encodage distant.
• Des fautes de page majeures ou de l’activité de swap rendront toute UI cassée.
• Une fréquence GPU bridée (profil d’alimentation) peut mimer un « mauvais GPU ».

Quatrième : le multi‑écran et le haut DPI changent la donne

• Plus de pixels signifie plus de bande passante et de grandes régions à repeindre.
• Des taux de rafraîchissement mismatched peuvent causer des jitters et un rythme bizarre.
• Docks + adaptateurs ajoutent des modes de défaillance (EDID, caps de bande passante, bizarreries de format couleur).

Cinquième : validez avec un micro‑test reproductible

• Test de déplacement/redimensionnement de fenêtre, défilement de texte et suivi du curseur sont basiques mais révélateurs.
• Capturez les logs immédiatement après reproduction ; n’attendez pas « plus tard ».

Tâches pratiques : commandes, sorties, ce qu’elles signifient et la décision à prendre

Ces tâches supposent Linux sur une station de travail ou un client VDI. Le but n’est pas la nostalgie ; c’est la clarté opérationnelle.
Exécutez-les dans l’ordre jusqu’à savoir si vous traitez une retombée de pilote, un problème de compositeur, une pression mémoire ou un goulot distant.

Task 1: Identify the GPU and which driver is bound

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 [102b:0534]
	Subsystem: Super Micro Computer Inc Device [15d9:0834]
	Kernel driver in use: mgag200
	Kernel modules: mgag200

Signification : Vous avez un appareil Matrox G200‑class lié à mgag200. C’est une voie serveur axée 2D.

Décision : Si le pilote est manquant ou « Kernel driver in use » est vide, corrigez d’abord le binding du pilote avant de blâmer les applications.

Task 2: Check if you’re accidentally running software rendering (Mesa llvmpipe)

cr0x@server:~$ glxinfo -B | egrep "OpenGL renderer|OpenGL vendor|OpenGL version"
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)
OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.0.4

Signification : Le rendu se fait sur le CPU via llvmpipe. Votre « problème GPU » est désormais un problème CPU.

Décision : Arrêtez‑vous. Corrigez DRI/pilote/compositeur pour que le renderer soit supporté par le matériel, ou acceptez un CPU plus élevé et ajustez en conséquence.

Task 3: Confirm Xorg is using the expected driver and acceleration method

cr0x@server:~$ grep -E "Driver|Acceleration|glamor|DRI" /var/log/Xorg.0.log | tail -n 20
[    18.224] (II) modeset(0): using drv /dev/dri/card0
[    18.224] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 630
[    18.226] (II) modeset(0): glamor initialized
[    18.241] (II) modeset(0): [DRI2] Setup complete

Signification : Xorg utilise modesetting avec l’accélération glamor et DRI2 activé.

Décision : Si vous voyez « falling back to shadowfb » ou « glamor failed », attendez‑vous à de mauvaises performances 2D et investiguez les paquets manquants ou les pilotes incompatibles.

Task 4: Check compositor and session type (Wayland vs X11)

cr0x@server:~$ echo "$XDG_SESSION_TYPE"
wayland

Signification : Vous êtes sur Wayland. Le débogage se déplace vers le compositeur (GNOME Shell, KDE KWin, etc.) et DRM/KMS.

Décision : Si vous avez besoin d’un comportement d’accélération X11 hérité (outils distants spécifiques, anciennes apps), testez une session X11 pour comparer.

Task 5: Inspect kernel DRM messages for modesetting and link issues

cr0x@server:~$ dmesg -T | egrep -i "drm|i915|amdgpu|nouveau|edid|hdmi|dp" | tail -n 30
[Tue Jan 13 08:41:02 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Tue Jan 13 08:41:03 2026] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[Tue Jan 13 08:41:05 2026] [drm:intel_dp_start_link_train] *ERROR* failed to train DP, aborting

Signification : Le pilote GPU est OK, mais l’entraînement de lien DisplayPort échoue — douleur classique de négociation dock/câble/moniteur.

Décision : Changez de câble/port de dock, baissez la fréquence de rafraîchissement, mettez à jour le firmware du dock. Ne perdez pas de temps à tuner le rendu tant que le lien n’est pas stable.

Task 6: Validate refresh rates and per-monitor modes

cr0x@server:~$ xrandr --verbose | egrep -A2 " connected|^\s+([0-9]{3,4}x[0-9]{3,4})"
DP-1 connected primary 3840x2160+0+0 (0x4b) normal (normal left inverted right x axis y axis) 597mm x 336mm
  3840x2160 (0x4b) 533.250MHz +HSync -VSync *current +preferred
HDMI-1 connected 1920x1080+3840+0 (0x5c) normal (normal left inverted right x axis y axis) 509mm x 286mm
  1920x1080 (0x5c) 148.500MHz +HSync +VSync *current +preferred

Signification : Résolutions mixtes. Cela augmente le coût de composition et peut exposer des bugs de mise à l’échelle.

Décision : Si les utilisateurs se plaignent de saccades, testez la correspondance des fréquences et des paramètres d’échelle ; le DPI mixte est un déclencheur fréquent de jank.

Task 7: Check for CPU saturation during “2D” actions

cr0x@server:~$ pidstat -u -p ALL 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(8 CPU)

08:52:10      UID       PID    %usr %system  %CPU  Command
08:52:11     1000      2123   85.00    8.00 93.00  gnome-shell
08:52:11     1000      2788   12.00    2.00 14.00  Xwayland

Signification : gnome-shell consomme le CPU. Cela signifie souvent fallback logiciel, effets lourds, ou interaction pilote/compositeur.

Décision : Réduisez animations/effets, testez différents réglages du compositeur, et vérifiez l’accélération matérielle (Task 2/3).

Task 8: Check memory pressure and swapping

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512000  82000 890000    0    0    12    20  410  900 12  4 84  0  0
 3  1  65536  48000  61000 210000    0  800   100   220 1200 2400 20  8 60 12  0

Signification : Swap‑out (so) est actif ; l’attente CPU (wa) augmente. Le jank UI peut être une pression mémoire pure.

Décision : Ajoutez de la RAM, réduisez la charge, ou corrigez une fuite mémoire. Ne blâmez pas le GPU pour ce que le pager a fait.

Task 9: Check GPU utilization and frequency (Intel example)

cr0x@server:~$ sudo intel_gpu_top -s 1000 -o - | head -n 12
freq  350 MHz  GPU  12%  RC6  75%  RCS  10%  BCS  2%  VCS  0%  VECS  0%
IMC reads:  820 MiB/s  IMC writes:  210 MiB/s

Signification : Le GPU est peu utilisé et la fréquence est assez basse ; pas forcément un problème à moins qu’il ne booste jamais quand la charge augmente.

Décision : Si la fréquence reste bloquée basse sous charge, vérifiez profils d’alimentation, réglages BIOS et paramètres noyau.

Task 10: Verify the active power profile (laptops and some desktops)

cr0x@server:~$ powerprofilesctl get
power-saver

Signification : Vous êtes en mode power‑saver. Cela peut plafonner GPU/CPU et produire de la lenteur « mystérieuse ».

Décision : Passez en balanced/performance pour les rôles affectés (traders, designers), ou acceptez le compromis explicitement.

Task 11: Remote session sanity check (RDP and network constraints)

cr0x@server:~$ ss -ti dst :3389 | head -n 12
ESTAB 0 0 10.10.8.21:52144 10.10.20.15:3389
	 cubic wscale:7,7 rto:204 rtt:42.1/8.2 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:22 bytes_sent:1849021 bytes_acked:1849010
	 retrans:12/45 lost:0 sacked:0

Signification : Des retransmissions sont présentes. Cela se traduit souvent par des artefacts visuels, de la latence et une interaction « collante » dans les bureaux distants.

Décision : Corrigez le réseau (Wi‑Fi, congestion, QoS). Ne touchez pas aux effets UI avant d’arrêter de perdre des paquets.

Task 12: Measure basic display pipeline errors and page flip behavior (DRM)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_display_info | head -n 20
CRTC info
  CRTC 0: active=yes (pipe A)
    output types: DP
    plane 0: enabled, fb=197, visible=3840x2160
    flip_pending=no

Signification : La pipeline d’affichage est active et les flips ne sont pas en attente. Si vous voyez flip_pending répété ou des erreurs, suspectez le compositeur ou un problème pilote/lien d’affichage.

Décision : Si ceci semble malsain, corrélez avec dmesg et les logs du compositeur ; priorisez la stabilité du lien avant les ajustements applicatifs.

Task 13: Check X11 rendering path issues via stderr logs (Xwayland / Xorg)

cr0x@server:~$ journalctl --user -b | egrep -i "xwayland|glamor|failed|dri" | tail -n 30
Jan 13 08:51:44 server Xwayland[2788]: glamor: Failed to initialize EGL.
Jan 13 08:51:44 server Xwayland[2788]: AIGLX: reverting to software rendering

Signification : Xwayland est retombé en rendu logiciel. Les anciennes apps X11 tireront la session vers le bas.

Décision : Corrigez la pile EGL/pilote ou exécutez une session X11 si votre charge est majoritairement X11.

Task 14: Check for USB display adapters (DisplayLink) that shift the bottleneck to CPU

cr0x@server:~$ lsusb | egrep -i "displaylink|graphics|dl-|evdi"
Bus 002 Device 004: ID 17e9:6006 DisplayLink USB Graphics Device

Signification : Vous utilisez un rendu de type DisplayLink. Cela peut fonctionner, mais ce n’est pas un « GPU gratuit ».

Décision : Si les plaintes de performance coïncident avec le graphisme USB, testez d’abord les sorties GPU natives ; si vous devez l’utiliser, prévoyez du CPU et ajustez les paramètres de compression.

Task 15: Quick check of PCIe link width/speed (yes, it can matter)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L1
LnkSta: Speed 2.5GT/s, Width x4

Signification : L’appareil peut faire x16 à 8GT/s mais fonctionne actuellement en x4 2.5GT/s. C’est une chute majeure de débit.

Décision : Rebranchez la carte, vérifiez les réglages BIOS et le câblage du slot. N’optimisez pas le logiciel au‑dessus d’un bus handicapé.

Task 16: Capture a “known-good” baseline for comparison (the boring tool that wins)

cr0x@server:~$ sudo inxi -Gxxx --filter
Graphics:
  Device-1: Intel UHD Graphics 630 driver: i915 v: kernel
  Display: wayland server: Xwayland v: 23.2.2 compositor: gnome-shell
  resolution: 3840x2160~60Hz, 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 23.0.4

Signification : Un instantané compact du GPU, du pilote, du serveur d’affichage et du renderer GL.

Décision : Conservez cette sortie pour chaque « golden image ». Quand une régression survient, comparez avant d’entrer en débat d’opinion.

Erreurs courantes : symptômes → cause racine → correction

1) Le curseur saccade mais le CPU semble correct

Symptôme : Le pointeur de la souris est lent ou laisse des traînées ; les utilisateurs disent qu’il « colle », surtout lors des déplacements de fenêtre.

Cause racine : Curseur matériel désactivé ou non fonctionnel ; chemin curseur logiciel lié au timing de repaint/compositeur.

Correction : Vérifiez le support par le pilote et le compositeur, contrôlez les problèmes dock/EDID, testez un autre type de session (X11 vs Wayland), et confirmez qu’il n’y a pas de fallback vers le rendu logiciel.

2) Le texte qui défile se déchire ou « macule »

Symptôme : Le défilement dans un terminal/navigateur montre des déchirures ou un redraw partiel.

Cause racine : Le compositeur n’utilise pas correctement le vsync, des fréquences mixtes, ou un chemin d’accélération endommagé (glamor/EGL en échec).

Correction : Alignez les fréquences de rafraîchissement quand c’est possible, mettez à jour les firmwares GPU/dock, et confirmez les réglages du compositeur ; vérifiez les logs pour glamor/EGL fallback.

3) CPU élevé lors des déplacements de fenêtres

Symptôme : Les déplacements de fenêtre font monter le CPU ; les ventilateurs s’accélèrent ; les métriques GPU paraissent inactives.

Cause racine : Rendu logiciel (llvmpipe) ou chemin graphique distant/USB qui encode sur le CPU.

Correction : Corrigez DRI et les paquets pilotes ; pour les sessions distantes, ajustez protocole et bande passante ; pour DisplayLink, prévoyez du CPU ou utilisez des sorties natives.

4) Tout va bien jusqu’à ce qu’un deuxième moniteur soit branché

Symptôme : L’ajout d’un moniteur provoque du jank, des clignotements noirs, ou des déconnexions intermittentes.

Cause racine : Limites de bande passante (mode DP/HDMI), entraînement de lien instable, quirks de firmware de dock, ou mise à l’échelle mismatchée.

Correction : Diminuez la fréquence, changez de câble/port, mettez à jour le firmware du dock, et testez une connexion directe (sans dock) pour isoler.

5) Le bureau distant devient « flou » en période de charge

Symptôme : Le texte devient doux ou en blocs pendant les heures de pointe.

Cause racine : Compression adaptative/réduction de qualité du protocole distant due à une perte de bande passante ou des retransmissions.

Correction : Corrigez la perte réseau, appliquez QoS, séparez les gros utilisateurs en une politique différente, et ajustez le protocole distant pour la fidélité du texte.

6) Rectangles noirs aléatoires durant le redraw d’une app

Symptôme : Flashs noirs brefs ou régions manquantes lors de changements rapides de fenêtres.

Cause racine : Régression pilote ou bug du compositeur dans le tracking des dommages / page flipping.

Correction : Revenez à un pilote connu‑bon, désactivez les flags problématiques du compositeur, et utilisez des déploiements en anneaux pour éviter un rollout massif.

Listes de contrôle / plan pas à pas

Étapes pas à pas : diagnostiquer un « bureau lent » sans tourner en rond

1. Classifiez l’environnement : GPU local vs VDI/RDP vs graphisme USB. Documentez-le dans le ticket.
2. Capturez l’identité de base : inxi -Gxxx, lspci -nnk, type de session, topologie des moniteurs.
3. Vérifiez le rendu logiciel : glxinfo -B renderer. Si llvmpipe, arrêtez‑vous et corrigez cela en premier.
4. Vérifiez les logs noyau et d’affichage : dmesg pour entraînement de lien et erreurs DRM.
5. Validez les modes des moniteurs : xrandr --verbose pour les mismatches de rafraîchissement et d’échelle.
6. Mesurez la pression système : CPU (pidstat), mémoire (vmstat), et pour sessions distantes, retransmissions (ss -ti).
7. Reproduisez avec un test minimal : défilement de texte, déplacement de fenêtre, suivi du pointeur, glisser multi‑écran.
8. Faites un changement à la fois : version du pilote, type de session, toggles du compositeur, ou fréquence de rafraîchissement. Enregistrez le résultat.
9. Stabilisez et standardisez : épinglez les versions et documentez les combos connus‑bons (GPU + pilote + dock + moniteur).

Checklist de déploiement : ne répétez pas les erreurs de 1997 avec du matériel 2026

• Gardez un ensemble testé de pilotes GPU épinglés par classe de matériel.
• Testez avec les périphériques réels : docks, adaptateurs et moniteurs que les gens possèdent réellement.
• Suivez les types de session par défaut (Wayland/X11) et sachez quelles apps cassent où.
• Ayez un plan de rollback qui ne nécessite pas une connexion héroïque à distance quand l’UI est cassée.
• Établissez des critères d’acceptation de « fidélité du texte » pour les bureaux distants, pas seulement des FPS.
• Documentez la politique de profil d’alimentation ; ne laissez pas des laptops expédiés en permanent power‑saver pour des rôles à forte interaction.

Ce qu’il faut reprendre de la pensée Matrox/S3/Tseng (même si vous touchez jamais au vieux matériel)

• Priorisez la correction ennuyeuse : un chemin stable et déterministe bat un chemin rapide avec corruption rare.
• Optimisez la boucle de perception : curseur matériel et redraw prévisible comptent plus que le débit de pointe.
• Respectez les couches de signal et de négociation : EDID, entraînement de lien et câblage font partie de la « performance graphique ».
• Concevez pour le comportement à l’échelle flotte : votre meilleure machine n’est pas l’indicateur ; vos pires 5 % le sont.

FAQ

1) Matrox, S3 et Tseng étaient‑ils « meilleurs » que les GPU modernes ?

En capacité brute, non. En comportement 2D prévisible sous les piles logicielles de leur époque, souvent oui.
Ils étaient optimisés pour les charges dominantes : primitives GDI/X11, curseurs stables et sortie cohérente.

2) Pourquoi les gens se souviennent‑ils de la sortie Matrox comme plus nette ?

La qualité VGA analogique dépendait du routage de la carte, de la qualité du RAMDAC, du filtrage et de la conception électrique. Certains fournisseurs traitaient cela comme une fonctionnalité de première classe.
Sur CRT, la différence était évidente : moins de scintillement, bords de texte plus nets.

3) Qu’est‑ce qui a fait de S3 un grand nom dans les bureaux ?

La facilité OEM : faible coût, fonctions intégrées, compatibilité étendue et pilotes qui fonctionnaient sur un large éventail de logiciels métier.
Ça gagne les batailles d’achats et réduit les tickets de support.

4) Quel est l’équivalent moderne de « l’accélération 2D » ?

La performance du compositeur, le tracking des dommages, les swaps de buffers efficaces et des pilotes GPU/affichage fiables. Les primitives ont changé de forme, mais le travail reste :
déplacer des pixels de façon prévisible avec une faible latence.

5) Si mon système utilise Wayland, dois‑je encore me soucier des problèmes 2D ?

Oui. Wayland change l’endroit où les problèmes apparaissent (compositeur/DRM plutôt que Xorg), mais vous pouvez toujours subir des fallback logiciel, de mauvais états d’alimentation, une instabilité de lien et des problèmes de timing multi‑écran.

6) Pourquoi un curseur matériel compte‑t‑il autant ?

Parce qu’il découple le feedback du pointeur du reste du pipeline de rendu. Les humains jugent la réactivité par le pointeur.
Un curseur fluide peut rendre un bureau lent tolérable ; un curseur lent rend tout cassé.

7) Comment savoir rapidement si « lenteur graphique » est en réalité une pression mémoire ?

Lancez vmstat 1 5. Si vous voyez swap‑in/swap‑out et une montée de l’attente I/O, votre UI se bat avec le pager.
Corrigez la RAM ou la charge avant de tuner la pile GPU.

8) Quelle est la cause moderne la plus courante de « 2D qui paraît mauvais » sur du matériel correct ?

Le fallback vers le rendu logiciel (llvmpipe), suivi de près par des problèmes de négociation dock/moniteur qui causent des liens instables ou des comportements étranges de rafraîchissement/mise à l’échelle.
Les deux sont détectables rapidement avec les tâches ci‑dessus.

9) Dois‑je forcer X11 parce que « c’est plus rapide » ?

N’en faites pas une religion. Testez. Certains workflows et pilotes se comportent mieux sur X11 ; d’autres sont plus fluides sur Wayland.
Choisissez le type de session qui offre un comportement cohérent pour votre mix d’apps et votre parc matériel.

10) Qu’est‑ce que les géants 2D nous ont appris sur la fiabilité ?

Que livrer moins de surprises vaut mieux que livrer plus de fonctionnalités. Ils considéraient le chemin « ennuyeux » — blits, curseurs, texte — comme le produit.
Les piles modernes devraient traiter les compositeurs, les docks et les rollouts de pilotes de la même façon.

Étapes suivantes

Si vous gérez des flottes — postes de travail, VDI, clients légers, salles de marché, laboratoires — appliquez la leçon de Matrox/S3/Tseng là où ça fait mal aujourd’hui :
la boucle d’interaction de base.

1. Construisez une baseline graphique connue‑bonne par classe matérielle (GPU + pilote + dock + moniteur).
2. Automatisez la capture de inxi -Gxxx, lspci -nnk, type de session et modes de moniteur pendant le provisioning.
3. Déployez en anneaux les changements graphiques (pilotes, mises à jour du compositeur, firmware de dock). Gardez un rollback déterministe.
4. Utilisez le mode d’emploi rapide quand les tickets arrivent. Classifiez d’abord, mesurez, puis ne changez qu’une chose à la fois.
5. Définissez des SLO visibles par l’utilisateur : fluidité du curseur, fidélité du texte en sessions distantes et stabilité multi‑écran. Pas seulement « utilisation GPU ».

Les géants 2D comptaient parce qu’ils traitaient le « dessin d’une fenêtre » comme critique. Vous devriez faire de même. Ce n’est pas du rétro. C’est de l’opérationnel.