3dfx Voodoo : la carte qui a rendu la 3D grand public

Avant Voodoo : pourquoi la 3D était un foutoir

En 1995, « la 3D sur PC » signifiait une loterie de chipsets, pilotes et API à moitié finies. Vous pouviez acheter un CPU rapide, une carte 2D correcte,
et vous retrouver malgré tout avec un diaporama dès que le jeu essayait d’appliquer des textures. La plupart des systèmes rendaient la 3D en logiciel sur le CPU.
Ça marchait, d’une certaine façon, et seulement si vous étiez généreux sur la définition de « marcher ».

Le problème de fond n’était pas que personne ne savait faire de la 3D. Les fabricants de silicium savaient. Les bornes d’arcade savaient. Les stations de travail savaient.
Le problème sur PC tenait à l’économie et à la fragmentation : chaque fournisseur avait une approche différente, des compromis différents et une qualité de pilote variable.
Les développeurs de jeux faisaient face à un choix que tout ingénieur plateforme reconnaît :
cibler le dénominateur commun et laisser de la performance sur la table, ou optimiser pour un environnement et aliéner tout le monde.

Dans ce chaos, 3dfx a livré un produit étroit, conçu pour un objectif précis et franchement impoli : « Ceci est uniquement pour la 3D.
Branchez-la à côté de votre carte 2D et profitez de ne pas écrire un rasteriseur logiciel. »
Ce n’était pas élégant. C’était efficace. Les systèmes de production le sont souvent.

Ce qu’était réellement la carte Voodoo (et ce qu’elle n’était pas)

Le succès grand public original est généralement connu sous le nom de « Voodoo Graphics » (souvent appelé Voodoo1 rétrospectivement).
C’était un accélérateur 3D dédié, pas une carte graphique complète au sens moderne. Il fallait toujours une carte 2D séparée pour Windows.
La Voodoo se plaçait sur le bus PCI, attendait qu’un jeu l’invoque, puis prenait en charge le signal vidéo via un câble de passthrough externe.

Ce câble externe ressemble à un hack parce que c’en était un. Mais c’était un hack choisi stratégiquement : il a permis à 3dfx d’expédier
sans lutter contre l’écosystème 2D du bureau et sans devoir être la carte unique qui doit fonctionner dans tous les modes Windows.
Si vous avez déjà isolé un sous-système risqué derrière un feature flag ou un proxy, vous avez vu le même instinct architectural.

Cela signifiait aussi que la Voodoo pouvait se concentrer sur ce qui importait pour les jeux : application de textures, Z-buffering, filtrage et compositing,
ajustés pour les résolutions courantes de l’époque. Elle n’avait pas à être généraliste. Elle devait être rapide là où les utilisateurs vivaient réellement.

L’ère deux-cartes et pourquoi c’était un compromis raisonnable

La configuration « deux cartes + câble » paraît ridicule aujourd’hui, mais c’était une séparation claire des responsabilités :
sortie 2D stable d’un côté, pipeline 3D spécialisé de l’autre.
Cela réduisait la zone d’impact en cas de problème. Si un jeu plantait, vous ne perdiez pas tout votre bureau.
À une époque où les pilotes pouvaient emmener le système d’exploitation avec eux, ça avait de l’importance.

Blague n°1 : Le câble de passthrough était le service mesh originel — sauf qu’il n’avait pas d’observabilité, et qu’il pouvait tomber derrière votre bureau pour toujours.

Comment ça fonctionnait : pipelines, passthrough, et pourquoi ça comptait

L’approche Voodoo était franche : accélérer les parties coûteuses en logiciel. Le CPU pouvait gérer la logique du jeu, la physique (telle qu’elle était),
et l’alimentation en triangles. La carte gérait le rastérisation et le texturing à une vitesse qu’un CPU milieu‑90s ne pouvait égaler.
Cette répartition du travail paraît évidente aujourd’hui. À l’époque, ce n’était pas évident sur le marché grand public, surtout aux tarifs abordables.

Un détail pratique clé : le pipeline Voodoo était conçu autour d’un matériel à fonctions fixes. Les développeurs n’écrivaient pas de shaders.
Ils sélectionnaient des modes. Ils géraient les textures. Ils vivaient avec des contraintes.
C’est très similaire à l’exploitation d’une base de données distribuée avec un modèle de requête fixe : les performances sont excellentes tant que vous respectez la forme du système.
Vous vous battez contre elle et vous perdrez.

Commutation en passthrough : « ça marche » jusqu’au jour où ça ne marche plus

Le câble externe du passthrough transportait les signaux VGA analogiques de la carte 2D vers la Voodoo puis vers le moniteur.
Quand un jeu passait en mode 3D, la Voodoo basculait la sortie sur elle-même. C’était simple et étonnamment robuste, mais ça ajoutait de nouveaux modes de défaillance :
dégradation douce de la qualité d’image, rémanence, mauvais câbles, et « pourquoi mon écran est noir ? » qui n’étaient pas du tout débogables en logiciel.

C’est là que le cerveau du journaliste et celui du SRE se serrent la main. La fonctionnalité est brillante. Le mode de défaillance est hostile pour l’utilisateur.
Vous pouvez avoir raison et malgré tout recevoir des pages.

Pourquoi ça donnait l’impression d’une révolution

Voodoo n’a pas créé la 3D. Elle a rendu la 3D cohérente. Vous pouviez acheter un jeu qui indiquait « 3dfx accelerated »
et vous attendre raisonnablement à ce qu’il soit fluide et joli sur une large gamme de systèmes.
Cela réduisait l’incertitude pour les clients et les développeurs, et l’incertitude est la taxe qui tue les marchés.

Glide : la voie rapide avec péage

Glide était l’API propriétaire de 3dfx. Elle était légère, orientée jeu et proche du matériel.
Les développeurs l’aimaient car elle produisait de bons résultats avec moins de douleur que les alternatives généralistes de l’époque.
Les utilisateurs l’aimaient parce que les jeux tournaient mieux.

Mais le péage était réel. Glide attachait les jeux au matériel 3dfx. Si vous n’étiez pas sur une Voodoo, vous étiez dans la voie lente.
Ce type d’optimisation verticale est enivrant quand on gagne — et suffocant quand la plate-forme change.
Si vous avez déjà vu une équipe construire des outils internes qui « ne fonctionnent que sur notre stack », vous avez observé la même histoire,
juste avec moins de polygones.

Direct3D et OpenGL : désordonnés, mais inévitables

L’industrie a convergé vers des API qui n’étaient pas contrôlées par un seul fournisseur. Elles ont été plus difficiles au début, parfois plus lentes,
et fréquemment moins prévisibles. Mais elles étaient portables, et la portabilité est un investissement qui se cumule.
Vous pouvez livrer une interface propriétaire incroyable, mais vous vous engagez aussi à maintenir tout l’écosystème pour toujours.
Les écosystèmes coûtent cher. Demandez à quiconque gère une rotation on‑call.

Ce qui a changé du jour au lendemain : attentes utilisateurs et gravité industrielle

Une fois l’accélération de classe Voodoo visible, il n’était plus possible de revenir en arrière. Effets d’éclairage, filtrage de textures,
taux de rafraîchissement plus élevés — ce n’étaient plus des « options sympas ». Ils sont devenus le socle de ce à quoi devait ressembler le jeu sur PC.
La carte ne se contentait pas de se vendre ; elle vendait l’idée qu’un matériel 3D était requis.

C’est le changement culturel subtil : quand une capacité devient grand public, elle cesse d’être une fonctionnalité et devient une dépendance.
Les dépendances créent des obligations : compatibilité, pilotes, support, performance prévisible. L’ère Voodoo a forcé l’écosystème PC
à prendre la 3D grand public au sérieux, entraînant systèmes d’exploitation, modèles de pilotes et outils de développement avec elle.

Cela a aussi changé la culture du benchmark. Les gens ont commencé à se soucier du framerate, pas seulement « est-ce que ça s’affiche ».
Et une fois que vous vous souciez des performances, vous commencez inévitablement à vous soucier de la mesure.
Tant mieux. La mesure est l’antidote à la superstition.

Anecdotes et contexte utiles au bar (ou en postmortem)

• Voodoo Graphics était un accélérateur uniquement 3D : il fallait une carte 2D séparée et un câble VGA de passthrough vers le moniteur.
• Glide est devenu une cible de facto : de nombreux jeux PC livraient des renderers 3dfx/Glide explicites car le gain de performances était évident.
• Voodoo2 a introduit le scan-line interleave (SLI) : deux cartes pouvaient se partager la charge de rendu en alternant les lignes de balayage pour plus de performances.
• « SLI » signifiait à l’origine scan-line interleave : le renommage sur les GPU modernes est apparenté dans l’esprit mais pas identique techniquement.
• Le marché a basculé vers des solutions 2D+3D mono‑carte : les consommateurs ne voulaient pas deux cartes et un câble indéfiniment ; l’intégration a gagné.
• La qualité des pilotes est devenue une arme concurrentielle : la vitesse comptait, mais « est‑ce que ça plante » et « est‑ce que ça marche dans ce jeu » pesaient plus que la communication.
• L’intégrité du signal analogique était réelle : des câbles passthrough bon marché et des cartes bruyantes pouvaient détériorer visiblement l’image 2D sur CRT.
• Les API se sont consolidées avec le temps : les chemins rapides propriétaires ont cédé la place à des API largement supportées à mesure que le coût développeur et la compatibilité dominaient.

Leçons SRE tirées d’une carte graphique de 1996

1) Un périmètre étroit bat un périmètre parfait

Voodoo a réussi en n’essayant pas d’être tout. Elle n’avait pas besoin d’exécuter le bureau. Elle devait rendre les jeux beaux et rapides.
Dans les systèmes de production, l’équivalent est un service avec une frontière nette et un SLO clair — puis une optimisation implacable à l’intérieur.
Un périmètre large vous fait finir par prendre en charge les cas limites de tout le monde.

2) La compatibilité est une fonctionnalité, pas une taxe

L’écosystème Voodoo a fonctionné parce qu’assez de jeux la ciblaient, et assez de systèmes pouvaient l’installer sans rituel sacrificiel.
Ce n’est pas de la magie ; c’est de l’ingénierie opérationnelle : pilotes, chemins d’installation, valeurs par défaut sensées et un modèle de support qui ne rejette pas l’utilisateur.
La fiabilité est une caractéristique produit.

3) Mesurez le temps de trame, pas les impressions

On argumentait sur le FPS alors comme on argumente aujourd’hui sur les percentiles de latence. L’instinct est correct : l’expérience utilisateur est façonnée par la consistance,
pas par les moyennes. Un 45 FPS stable donne souvent une meilleure sensation qu’un 90 FPS avec des pics. Idem pour les services :
un p95 stable vaut mieux qu’un p50 héroïque. N’optimisez pas le nombre qui vous fait vous sentir bien.

4) Le « chemin rapide » est un engagement

Glide était un chemin rapide. Les chemins rapides sont attractifs parce qu’ils rendent votre meilleur cas spectaculaire.
Ils sont dangereux parce qu’ils créent deux mondes : le monde où tout est rapide et le monde où tout est cassé.
Si vous construisez un chemin rapide, vous créez aussi une charge de tests, une histoire de secours et un plan de migration. Sinon, vous construisez une future panne.

5) De petits détails physiques peuvent devenir votre plus gros problème de fiabilité

Un câble VGA fragile peut ruiner l’expérience même si le silicium est parfait. Dans un datacenter, ce sont le transceiver lâche,
la fibre mal étiquetée, l’alimentation avec une mauvaise masse, ou le câble de fortune qui survit à votre organigramme.

6) Une citation à garder au mur

« L’espoir n’est pas une stratégie. » —General Gordon R. Sullivan

L’ère Voodoo a récompensé les équipes qui testaient de vrais jeux sur de vraies machines, pas celles qui espéraient que le pilote se comporterait.
C’est la même chose aujourd’hui. L’espoir ne vous appelle pas ; la réalité, si.

Tâches pratiques : vérifier, mesurer, et décider (avec commandes)

Ces tâches supposent que vous exploitez un poste de travail Linux, une machine de build rétro-gaming, ou une machine de labo utilisée pour benchmarking/émulation.
L’objectif n’est pas que vous puissiez exécuter une Voodoo sur Linux moderne ; l’objectif est de développer la mémoire musculaire :
inventorier le matériel, confirmer les pilotes, valider le chemin de rendu, puis trouver le goulot avec des preuves.

Tâche 1 : Identifier le(s) GPU et lier les pilotes kernel

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+4p'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] [10de:1c03] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:11c3]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Ce que ça signifie : Vous voyez le périphérique et quel pilote le gère.
Décision : Si « Kernel driver in use » manque ou est incorrect, corrigez l’association du pilote avant de chasser la performance.

Tâche 2 : Vérifier si OpenGL est rendu en logiciel (piège classique « pourquoi c’est lent »)

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Ce que ça signifie : Vous utilisez un vrai pilote GPU, pas Mesa llvmpipe.
Décision : Si le renderer affiche « llvmpipe » ou « Software Rasterizer », arrêtez — corrigez d’abord la pile pilote/GL.

Tâche 3 : Vérifier le chemin Vulkan (utile pour wrappers/émulateurs modernes)

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

Instance Extensions: count = 20
==============================
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
...

Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceID           = 0x1c03
	deviceName         = NVIDIA GeForce GTX 1060 6GB

Ce que ça signifie : La pile Vulkan voit le GPU et le pilote.
Décision : Si aucun device n’apparaît, vous n’avez pas de pile Vulkan utilisable — évitez les couches de traduction basées sur Vulkan tant que c’est cassé.

Tâche 4 : Mesurer l’échelle de fréquence CPU (mystère de performance n°1)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|MHz'
CPU(s):                               16
Model name:                           AMD Ryzen 7 5800X 8-Core Processor
CPU MHz:                              3699.906

Ce que ça signifie : MHz courant rapporté et topologie.
Décision : Si le MHz reste très bas sous charge, corrigez le gouverneur d’alimentation/throttling thermique avant de blâmer le GPU.

Tâche 5 : Confirmer les clocks GPU et l’état de throttling

cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,pstate,temperature.gpu,utilization.gpu --format=csv
clocks.gr [MHz], clocks.mem [MHz], pstate, temperature.gpu, utilization.gpu [%]
1770, 4006, P2, 67, 35

Ce que ça signifie : Vous pouvez voir si le GPU booste et si l’utilisation est significative.
Décision : Faible utilisation avec FPS bas pointe vers CPU/overhead pilote, stalls de sync, ou mauvais chemin de rendu.

Tâche 6 : Valider la largeur et la vitesse du lien PCIe (les goulots bus existent toujours)

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
LnkSta:	Speed 8GT/s (ok), Width x16 (ok)

Ce que ça signifie : Le GPU fonctionne à la largeur/vitesse de lien attendue.
Décision : Si vous voyez x1 ou une vitesse dégradée, reseat le matériel, vérifiez les réglages BIOS, et inspectez risers/câbles.

Tâche 7 : Vérifier l’attente I/O système et les changements de contexte pendant un benchmark

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
 1  0      0 312456  66240 845320    0    0    12    24  684 1250 12  3 85  0  0
 2  0      0 309812  66240 845988    0    0     0     0  722 1890 28  6 66  0  0
 3  0      0 307220  66240 846112    0    0     0     0  740 2055 35  7 58  0  0
 1  0      0 306900  66240 846220    0    0     0     0  701 1622 25  4 71  0  0
 1  0      0 306500  66240 846330    0    0     0     0  690 1501 18  3 79  0  0

Ce que ça signifie : Si wa est élevé, vous attendez le disque ; si cs explose, vous pourriez être lié au scheduling.
Décision : Un iowait élevé signifie que votre « problème GPU » est probablement du streaming d’actifs ou du swap ; corrigez le stockage/pression mémoire.

Tâche 8 : Voir quels processus consomment réellement du CPU pendant le « benchmark »

cr0x@server:~$ pidstat -u 1 3
Linux 6.6.12 (server) 	01/13/2026 	_x86_64_	(16 CPU)

12:10:01     UID       PID    %usr %system  %guest   %CPU   CPU  Command
12:10:02    1000     18421   92.00    6.00    0.00  98.00     7  retroarch
12:10:02       0      1542    1.00    2.00    0.00   3.00     1  Xorg
12:10:02    1000      2310    0.00    1.00    0.00   1.00     3  pulseaudio

Ce que ça signifie : L’émulateur/jeu est lié au CPU (un cœur saturé).
Décision : Optimisez l’affinité des cœurs, les paramètres de l’émulateur ou l’overhead de traduction ; un upgrade GPU n’aidera pas beaucoup.

Tâche 9 : Confirmer si le système swap (poison de latence)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        21Gi       1.2Gi       1.1Gi       9.0Gi        8.7Gi
Swap:          2.0Gi       1.6Gi       400Mi

Ce que ça signifie : Le swap est utilisé ; s’il augmente pendant les runs, la performance va fluctuer.
Décision : Ajoutez de la RAM, réduisez les processus en arrière-plan, ou ajustez swappiness ; ne chassez pas la « saccade GPU » tant que le swap persiste.

Tâche 10 : Vérifier dmesg pour resets GPU et erreurs PCIe

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|amdgpu|i915|pcie|AER|reset' | tail -n 12
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:1c.0
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:   device [1022:1453] error status/mask=00000001/00002000
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:    [ 0] RxErr

Ce que ça signifie : Erreurs PCIe corrigées. Ce n’est pas fatal, mais rassurant, non.
Décision : Si elles coïncident avec des saccades/plantages, inspectez le slot, le riser, la stabilité PSU ; ne perdez pas de temps à tuner le logiciel en premier.

Tâche 11 : Mesurer la latence de stockage (le stutter lié au streaming d’actifs est réel)

cr0x@server:~$ iostat -x 1 3
Linux 6.6.12 (server) 	01/13/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    4.92    0.21    0.00   76.75

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         72.00   9140.00     0.00   0.00    0.35   126.94   15.00   1920.00    0.62   0.03   3.10

Ce que ça signifie : r_await/w_await sont bas ; %util est bas : le stockage n’est pas votre goulot.
Décision : Passez au synchronisation CPU/GPU et au chemin de rendu ; n’optimisez pas le disque par ennui.

Tâche 12 : Vérifier les limites de descripteurs de fichiers (oui, les jeux et lanceurs peuvent déclencher ça)

cr0x@server:~$ ulimit -n
1024

Ce que ça signifie : 1024 fichiers ouverts max pour le shell/processus.
Décision : Si un lanceur ou un émulateur charge beaucoup d’actifs/plugins, augmentez les limites ; évitez de courir après des « plantages aléatoires » qui ne sont que de l’épuisement FD.

Tâche 13 : Valider que vous n’exécutez pas en session distante avec rendu logiciel forcé

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Ce que ça signifie : Type de session local. Le forwarding X11 sur SSH et certains environnements imbriqués peuvent handicaper l’accélération.
Décision : Si vous êtes en SSH X11 forwarding ou une VM contrainte, benchtez localement ou avec un passthrough GPU approprié.

Tâche 14 : Contrôle sanity du throttling thermique (tueur silencieux de performances)

cr0x@server:~$ sensors | sed -n '1,35p'
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.9°C
Tdie:         +83.9°C

nvme-pci-0100
Adapter: PCI adapter
Composite:    +44.9°C

Ce que ça signifie : La température CPU est élevée ; vous pouvez approcher du throttling selon la plateforme.
Décision : Corrigez le refroidissement avant d’optimiser les chemins ; le throttling rend chaque mesure mensongère.

Blague n°2 : Si vos résultats de benchmark changent après avoir ouvert le boîtier, félicitations — vous avez inventé l’autoscaling basé sur le flux d’air.

Mode opératoire de diagnostic rapide : trouver le goulot vite

L’objectif n’est pas d’être malin. L’objectif est d’être rapide, reproductible et suffisamment correct pour choisir la prochaine action.
Faites ceci dans l’ordre. Écartez-vous seulement si vous avez une bonne raison et que vous pouvez l’expliquer à quelqu’un d’autre.

Première étape : vérifier le chemin de rendu et la réalité du pilote

• Confirmer que le pilote GPU est lié (lspci -nnk).
• Confirmer qu’OpenGL/Vulkan utilise le matériel, pas le logiciel (glxinfo -B, vulkaninfo --summary).
• Vérifier les logs pour resets et bruit PCIe/AER (dmesg -T filtres).

Gate de décision : Si vous faites du rendu logiciel, arrêtez. Réparez cela. Tout le reste est du bruit en aval.

Deuxième étape : décider CPU-bound vs GPU-bound avec un passage de mesures

• Surveillez la saturation des cœurs CPU (pidstat -u).
• Surveillez l’utilisation GPU et les clocks (nvidia-smi ou équivalent vendor).
• Vérifiez le swap et la pression mémoire (free -h).

Gate de décision : Si un cœur CPU est bloqué et que le GPU est inactif, vous êtes lié au CPU/overhead pilote.
Si le GPU est saturé et que le CPU a de la marge, vous êtes lié GPU. Si les deux sont bas, vous êtes bloqué sur sync, I/O ou configuration.

Troisième étape : éliminer les goulots « non évidents »

• Latence stockage (iostat -x) si streaming/stutter.
• Largeur du lien PCIe (lspci -vv) si les performances semblent plafonnées.
• Thermiques (sensors, températures GPU) pour éviter de chasser des résultats throttlés.

Gate de décision : Si thermiques ou lien PCIe sont incorrects, corrigez le matériel ou les réglages firmware avant d’optimiser le logiciel.

Erreurs communes : symptôme → cause racine → correctif

Écran noir quand le jeu passe en 3D

Symptôme : L’affichage devient noir en entrant en mode accéléré ; le bureau revient à la sortie, parfois.

Cause racine : À l’époque Voodoo : câble passthrough défectueux, fréquence de rafraîchissement non supportée, ou problèmes de synchronisation du moniteur.
Dans les setups modernes : mauvais mode plein écran, conflit de compositeur, ou reset GPU.

Correctif : Forcer une résolution/rafraîchissement sûre ; changer les câbles ; éviter les adaptateurs exotiques ; vérifier les logs pour resets GPU ; tester plein écran exclusif vs borderless.

Moyenne FPS élevée, mais le jeu « donne une mauvaise impression »

Symptôme : Le benchmark indique un FPS élevé, mais le mouvement est irrégulier et l’entrée semble laggée.

Cause racine : Problèmes de pacing des frames : temps de trame inégaux dus à des pics CPU, compilation de shaders à la volée, ou problèmes de sync (vsync/profondeur de file).

Correctif : Capturer les temps de trame (pas seulement le FPS) via vos outils ; réduire la charge en arrière-plan ; précompiler les shaders si possible ; tester vsync et limiteurs de framerate.

Performance plafonnée à un plafond étrangement bas

Symptôme : Peu importe les réglages, vous ne dépassez pas un FPS bas (p.ex. 30/60/75) ou le GPU refuse de booster.

Cause racine : Cap vsync, mismatch de rafraîchissement, état de gestion d’alimentation, ou lien PCIe négocié en bas (x1/x4).

Correctif : Valider la fréquence de rafraîchissement, désactiver vsync pour les tests, vérifier largeur/vitesse PCIe, contrôler pstate et le gouverneur GPU.

Plantages qui n’arrivent que sur une machine

Symptôme : Même build, même jeu, stabilité différente selon la machine.

Cause racine : Versions de pilotes, overclocks instables, PSU marginal, erreurs PCIe corrigées évoluant sous charge, ou RAM défaillante.

Correctif : Épingler les versions de pilotes ; supprimer les overclocks ; lancer des tests mémoire ; vérifier dmesg pour AER ; traiter les « erreurs corrigées » comme un avertissement précoce.

« Ça marchait hier » après une mise à jour routinière

Symptôme : Régressions soudaines sans changements de code dans le jeu/émulateur.

Cause racine : Changements dans la pile GL/Vulkan, mise à jour Mesa/NVIDIA, mise à jour du compositeur, ou régression du kernel.

Correctif : Revenir en arrière et bisecter ; garder des paquets pilotes connus bons ; capturer des métriques de référence (clocks GPU, FPS, temps de trame) comme validation routinière.

L’image paraît floue ou bruitée (spécifique rétro mais instructif)

Symptôme : Le texte du bureau ou la sortie 2D paraît pire après avoir ajouté une carte 3D (plaintes classiques du passthrough Voodoo).

Cause racine : Dégradation du signal analogique via le câble et les connecteurs du passthrough.

Correctif : Utiliser un câble court et de bonne qualité ; éviter les adaptateurs bon marché ; garder les longueurs de câble courtes ; accepter que l’analogique est une couche physique qui a son avis.

Trois mini-histoires d’entreprise issues des mines de compatibilité

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

Nous avions un outil de visualisation graphique intensif utilisé pour les revues d’incidents — ironique, oui. Il tournait localement sur les machines des ingénieurs et aussi en mode CI-render
qui produisait de courts clips pour la documentation. Un changement est arrivé pour « standardiser » le backend de rendu : si OpenGL était disponible, on l’utilisait ;
sinon on retombait sur le rendu logiciel.

La mauvaise hypothèse était subtile : « OpenGL disponible » a été interprété comme « accélération matérielle disponible ». Sur une sous‑population d’ordinateurs portables, la pile pilote
fournissait silencieusement OpenGL via un rasterizer logiciel. C’était techniquement correct, et opérationnellement catastrophique.
Les jobs CI ont commencé à expirer ; les portables sonnaient comme de petits avions ; l’outil a eu la réputation d’être instable.

Les premières tentatives de debug ont suivi les directions improductives habituelles : blâmer le nouvel algorithme, chasser des fuites mémoire, et discuter des modèles de portables.
La percée est venue quand une personne a posé la question ennuyeuse : « Que dit glxinfo -B sur les machines qui échouent ? »
Ça affichait « llvmpipe ». Problème trouvé.

Nous avons corrigé la logique de détection. Nous ne demandions plus « OpenGL est-il présent », mais « est‑ce matériel ? ».
Si non, nous forçons le renderer simple avec avertissements explicites. Nous avons aussi ajouté un autotest au démarrage qui imprimait la chaîne du renderer dans les logs.
Pas d’héroïsme. Juste un prédicat correct.

C’est la leçon Voodoo en tenue moderne : vous n’avez pas le droit de supposer que le chemin rapide est actif. Vous le vérifiez.
Le système vous mentira poliment jusqu’à ce que vous demandiez des preuves.

Mini-histoire n°2 : L’optimisation qui s’est retournée contre nous

Une autre équipe a livré une « optimisation » pour réduire la latence de bout en bout dans un environnement bureau à distance utilisé pour un labo.
Ils ont augmenté le cap de framerate et désactivé une étape de synchronisation pour laisser les frames circuler. La démo avait l’air fluide dans le meilleur des cas.
Ils l’ont poussée large parce que personne n’aime être la personne qui dit « non » à un gain de performance.

Ce qui a été manqué, c’est le pacing des frames sous charge. Désactiver l’étape de sync a provoqué des files de frames imprévisibles.
Les utilisateurs ont vu des micro-stutters et parfois du « rubber banding » en entrée, malgré un FPS moyen plus élevé.
Les plaintes ont afflué, et l’équipe a eu le classique problème « mais les métriques sont meilleures ».

Le postmortem a porté sur la mesure de la bonne chose. Le FPS moyen a augmenté, mais le p95 du temps de trame s’était dégradé.
Plus important, le comportement en queue corrélait avec des pauses GC dans un composant séparé et avec du jitter réseau.
L’optimisation n’avait pas éliminé un goulot ; elle avait supprimé un stabilisateur.

Le rollback a résolu le problème. La correction suivante était plus ennuyeuse : caler le framerate sur une valeur stable, réintroduire la synchronisation,
et ajouter une logique de buffering qui privilégiait un pacing cohérent plutôt que le débit de pointe. Les utilisateurs ont arrêté de remarquer le système,
ce qui est le plus grand compliment qu’une plateforme puisse recevoir.

Le parallèle Voodoo : l’accélération matérielle rend les choses rapides, mais l’expérience gagnante est prévisible.
Les gens se souviennent de la « fluidité », pas des pics. Optimisez la sensation, pas le chiffre à exhiber.

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

Un petit groupe d’infra maintenait un labo de machines hétérogènes pour la QA : GPU différents, branches de pilotes différentes,
et images OS variées. C’était coûteux à maintenir, et ça ne remportait aucun prix. Ça a aussi empêché une panne coûteuse.

Une nouvelle build d’une application type CAO avait l’air correcte sur les postes principaux des développeurs. La release était planifiée.
Le labo a exécuté la suite de régression sur les machines « coins bizarres » — pilotes plus anciens, GPU alternatifs, et quelques systèmes avec écrans atypiques.
Deux échecs sont apparus : un crash pilote sur une branche spécifique ; l’autre une corruption de rendu quand une certaine extension était présente.

L’équipe n’a pas paniqué pour « réparer les pilotes ». Ils ont fait ce que font les équipes ops matures : rétrécir le périmètre et contrôler les variables.
Ils ont épinglé une version de pilote connue bonne pour la release et ajouté une détection d’extension à l’exécution pour éviter le chemin bogué.
L’app est sortie sans une tempête de tickets support.

Personne en dehors de l’équipe n’a remarqué. C’est le but.
La pratique — maintenir un labo de compatibilité ingrat et épingler les dépendances — s’est remboursée en empêchant un incident public.
C’était l’équivalent corporate de garder un câble de passthrough de rechange dans le tiroir et de l’étiqueter comme si vous le pensiez vraiment.

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

Étape par étape : évaluer un « problème d’accélération 3D » sans perdre votre après-midi

1. Inventorier le matériel et les pilotes.
   Utilisez lspci -nnk. Confirmez que le bon pilote kernel est lié.
   Si ce n’est pas le cas, corrigez cela d’abord.
2. Vérifier que l’accélération matérielle est réelle.
   Utilisez glxinfo -B (et vulkaninfo si pertinent).
   Si vous voyez des renderers logiciels, arrêtez et réparez la pile graphique.
3. Établir une exécution de référence.
   Choisissez une scène/benchmark reproductible et lancez‑la deux fois. Si les résultats diffèrent fortement, votre environnement n’est pas assez stable pour tuner.
4. Classer la direction du goulot.
   Observez la saturation des cœurs CPU (pidstat) et l’utilisation/clocks GPU (nvidia-smi).
5. Éliminer la pression mémoire.
   Vérifiez free -h. Si le swap bouge, réglez la mémoire d’abord.
6. Éliminer les stalls I/O.
   Utilisez iostat -x pendant un run. Si les awaits grimpent et %util se bloque, vous êtes bound par le stockage.
7. Vérifier la couche physique/firmware.
   Confirmez la largeur/vitesse du lien PCIe. Vérifiez dmesg pour erreurs AER. Contrôlez les thermiques.
8. Ce n’est qu’ensuite que vous tunez les paramètres.
   Quand vous tunez, changez une variable à la fois et prenez des notes. Traitez cela comme une expérience, pas une session de ressenti.

Checklist : sécuriser une fonctionnalité « chemin rapide » (la leçon Glide)

• Avoir un mécanisme explicite pour détecter si le chemin rapide est actif.
• Logger le chemin détecté dans un endroit récupérable a posteriori.
• Maintenir un chemin de repli plus lent mais correct.
• Tester régulièrement les deux chemins ; sinon le repli devient une mythologie.
• Épingler les dépendances pour les releases ; ne « flottez » pas les versions pilotes/outils sauf si vous aimez les surprises.

Checklist : essentiels d’un labo de compatibilité (assurance peu coûteuse)

• Au moins une machine par grand fournisseur de GPU/branche pilote que vous prétendez supporter.
• Une machine « plus bas dénominateur commun » représentant le bas de votre base d’utilisateurs.
• Tests smoke automatisés qui valident la sélection du backend de rendu et loggent les chaînes renderer.
• Images OS reproductibles ou gestion de configuration pour remettre rapidement les machines à l’état initial.
• L’habitude d’exécuter la suite labo avant les releases, pas après les incidents.

FAQ

La Voodoo originale était‑elle un « GPU » comme on l’entend aujourd’hui ?

Fonctionnellement elle accélér[ait] le rendu 3D, donc oui dans l’esprit. Architectur[ellement] c’était un add-in 3D-only qui dépendait d’une carte 2D séparée et d’un passthrough analogique.
Les GPU modernes gèrent généralement 2D/desktop et 3D, avec pilotes unifiés et sorties numériques.

Pourquoi 3dfx a‑t‑elle utilisé un câble de passthrough au lieu d’être la seule carte vidéo ?

Cela réduisait la portée et le risque de compatibilité : 3dfx n’avait pas besoin de maîtriser chaque mode desktop et chaque coin d’accélération 2D.
Ils pouvaient se concentrer sur la performance 3D et arriver rapidement sur le marché. Le compromis était des câbles supplémentaires et des problèmes de qualité de signal analogique.

Qu’est‑ce qui rendait Glide si attractif pour les développeurs ?

Il était plus simple, plus proche du matériel et optimisé pour les besoins courants des jeux de l’époque.
Il réduisait la douleur des développeurs et offrait de meilleures performances sur le matériel Voodoo comparé aux alternatives incohérentes.

Glide était‑il « mauvais » parce que propriétaire ?

Propriétaire n’est pas automatiquement mauvais ; c’est un compromis. Glide produisait rapidement une vraie valeur utilisateur.
Le coût était l’enfermement dans l’écosystème et la fragilité à long terme quand le marché a basculé vers des API largement supportées et des cartes intégrées.

Qu’est‑ce que le SLI Voodoo2 et comment ça fonctionnait ?

Voodoo2 pouvait être associée à une seconde carte en scan-line interleave : une carte rendait des lignes horizontales alternées.
Ça augmentait les performances et supportait des résolutions plus élevées pour l’époque, mais ajoutait coût, complexité et contraintes de compatibilité.

Pourquoi l’industrie s’est‑elle éloignée des « accélérateurs 3D add-on spécialisés » ?

L’intégration a gagné sur le coût, la simplicité et l’expérience utilisateur. Une carte, un ensemble de pilotes, moins de câbles, moins de modes de défaillance.
Une fois que les cartes 2D+3D intégrées étaient assez bonnes, l’approche deux-cartes est devenue une complication inutile.

Quel est l’enseignement le plus « pertinent SRE » de l’ère Voodoo ?

Vérifiez le chemin rapide. Ne le supposez pas. Instrumentez‑le.
Beaucoup d’incidents de production ne sont que : « on pensait que l’accélération/caching/réplication était active, mais elle ne l’était pas. »

Si je dépanne des saccades aujourd’hui, quel est l’équivalent moderne des « problèmes de câble passthrough » ?

La couche physique mord toujours : risers PCIe défaillants, alimentation marginale, throttling thermique, ou bizarreries de câble/adaptateur d’écran.
Aussi : compositeurs, overlays et outils de capture qui s’injectent dans les chemins de rendu.

La Voodoo a‑t‑elle changé la façon dont les gens achetaient des PC ?

Oui. Elle a contribué à normaliser l’idée qu’un PC avait besoin d’un matériel 3D dédié pour les jeux sérieux.
Elle a aussi fait entrer la « marque de la carte graphique et la qualité des pilotes » dans les facteurs d’achat grand public, pas seulement une obsession de niche.

Quelle est la pratique ennuyeuse qui mappe le mieux à l’histoire Voodoo ?

Épingler et tester pilotes/outils. Maintenir une matrice de compatibilité.
Le marché a puni les systèmes rapides en labo mais instables en production, et il en va de même pour les stacks modernes.

Conclusion : prochaines étapes pratiques

La 3dfx Voodoo a rendu la 3D grand public en réussissant trois choses : réduire le périmètre, livrer un chemin rapide apprécié des développeurs, et assurer une expérience cohérente.
Elle a aussi montré le coût à long terme d’une accélération propriétaire et la réalité opérationnelle que de petits détails physiques peuvent dominer la qualité perçue.

Si vous construisez ou exploitez quoi que ce soit de sensible aux performances — rendu, vidéo, traitement de données, « IA », choisissez votre buzzword — prenez ces prochaines étapes :

1. Ajoutez un auto‑rapport du « chemin de rendu » (ou indicateur de chemin rapide) dans les logs et rapports de bug. Rendez‑le impossible à rater.
2. Baselinez le temps de trame et la latence tail, pas seulement les moyennes. Choisissez une métrique que vous pouvez défendre en postmortem.
3. Créez un petit labo de compatibilité si vous supportez des clients hétérogènes. Une machine bizarre aujourd’hui évite dix tickets demain.
4. Épinglez les dépendances pour les releases — pilotes, toolchains, runtimes — et testez les montées de version volontairement, pas accidentellement.
5. Gardez vos « câbles de passthrough » sous contrôle : étiquetez la couche physique, auditez-la, et traitez les erreurs corrigées comme des signaux d’alerte précoces.

L’héritage de Voodoo n’est pas la nostalgie. C’est le rappel que le grand public arrive quand la performance devient fiable — et le fiable est rarement glamour.