3dfx : l’ascension et le déclin d’une légende du jeu vidéo

décembre 12, 2025 • février 3, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Si vous avez déjà livré un produit qui est soudainement devenu « l’option par défaut », vous savez que la phase suivante n’est pas la victoire : c’est la latence.
Pas la latence réseau. La latence organisationnelle. Le temps entre le changement de la réalité et l’admission par votre entreprise.

3dfx a vécu cette courbe en public. Ils ont fait passer les graphismes 3D de la curiosité à la nécessité, puis ont perdu le fil dans un marché où
le « suffisamment bon » sort chaque semaine, et le « parfait » arrive après que le client soit passé à autre chose.

Ce que 3dfx a bien fait : un produit simple qui a résolu un véritable goulot d’étranglement

Le PC du milieu des années 1990 était une bête étrange : beaucoup d’ambition CPU, beaucoup d’ambition logicielle, et des chaînes graphiques maintenues avec du scotch.
Les développeurs voulaient le texture mapping, le z-buffering, le filtrage et des résolutions plus élevées sans transformer chaque image en diaporama.
De leur côté, les consommateurs voulaient la chose que demandent toujours les consommateurs : « Faites que ça ressemble à la capture sur la boîte. »

Le génie initial de 3dfx n’était pas mystique. C’était opérationnel. Ils ont restreint l’énoncé du problème.
Ils n’ont pas essayé d’être d’emblée un contrôleur d’affichage complet et une carte 2D pour le bureau. Ils ont livré un accélérateur qui rendait le chemin chaud rapide :
rasteriser des triangles, appliquer des textures, rendre suffisamment fluide pour que les gens arrêtent de penser au rendu et commencent à penser au jeu.

En termes de production, 3dfx a trouvé le chemin critique et y a envoyé du matériel spécialisé. C’est tout.
Le marché a récompensé cette clarté : les joueurs ont acheté la carte qui rendait les jeux subitement « justes », et les développeurs ont ciblé ce que les clients possédaient.
Effet de réseau, mais avec des polygones.

Neuf faits qui expliquent l’époque (sans la brume nostalgique)

Le premier succès de 3dfx, Voodoo Graphics (1996), était principalement une carte 3D additionnelle ; on la chaînait souvent à une carte 2D séparée via un câble pass-through.
Glide était l’API propriétaire de 3dfx ; de nombreux jeux Windows proposaient des renderers Glide parce que c’était pratique et prévisible sur le matériel Voodoo.
Voodoo2 (1998) a popularisé l’évolutivité grand public multi-cartes avec SLI (« scan-line interleave »), en scindant des lignes horizontales alternées entre deux cartes.
La « 3D acceleration » est devenue une catégorie d’achat plus vite que beaucoup d’OEM ne pouvaient redessiner les systèmes ; les cartes add-in étaient la voie la plus courte pour le marché.
Le RIVA TNT puis le GeForce 256 de NVIDIA ont avancé rapidement vers l’intégration 2D/3D et un rythme plus soutenu, réduisant l’attrait d’une configuration 3D dédiée.
3dfx a acquis STB Systems (1998), un fabricant de cartes, basculant d’un modèle de fournisseur de puces vers la fabrication et la vente de cartes de marque.
La qualité des pilotes et la vitesse de livraison sont devenues des dimensions compétitives, pas une réflexion après coup—surtout quand le jeu sous Windows est passé du hobby au grand public.
Le Voodoo3 de 3dfx était performant sur certains workloads réels mais peinait face à des listes de fonctionnalités en rapide évolution (notamment les attentes en couleur 32 bits et l’élan marketing du T&L).
Fin 2000, NVIDIA a acquis les actifs de 3dfx, mettant fin à 3dfx en tant que concurrent indépendant et clôturant un chapitre déterminant de l’histoire des graphismes PC.

Comment Voodoo fonctionnait réellement : choix d’architecture qui ont compté

Le succès précoce de Voodoo n’était pas seulement « une puce rapide ». C’était le type de frontière produit que les SRE adorent :
un service étroit et bien défini qui fait une chose extrêmement bien.
La carte Voodoo Graphics se concentrait sur le pipeline 3D tout en laissant le 2D à une carte graphique existante.
Cela paraît maladroit maintenant, mais à l’époque cela réduisait la complexité et le time-to-market.

Le design à câble pass-through signifiait que vous ne remplaciez pas tout le sous-système vidéo ; vous l’augmentiez.
Cela diminuait la friction pour les consommateurs et les OEM. Ça a aussi limité le périmètre de 3dfx — un avantage sous-estimé.
Moins de fonctionnalités à implémenter signifie moins de modes de défaillance. Ce n’est pas glamour, mais ça livre.

Le matériel mettait l’accent sur le texture mapping et le fill rate à un moment où c’étaient les points douloureux.
Les jeux passaient des polygones plats aux mondes texturés. Si vous pouviez texturer vite et filtrer correctement,
vous faisiez paraître le jeu coûteux même lorsque la géométrie restait basique.

Puis le monde a changé. La « frontière de service » (accélérateur 3D uniquement) est devenue un handicap à mesure que l’intégration s’améliorait.
Le système voulait un seul périphérique pour 2D + 3D, des piles de pilotes plus serrées, moins de câbles, moins de problèmes de compatibilité.
Ce qui avait commencé comme une interface propre a commencé à ressembler à une rustine.

Un regard production : frontières, ownership et coût de la colle

L’approche pass-through est la version matérielle du « on ajoutera juste un sidecar ». Les sidecars sont géniaux jusqu’à ce que vous deviez les déboguer à 2 h du matin.
Quand le marché attend une carte, un modèle de pilote, un vendeur à blâmer, la frontière supplémentaire cesse d’être de la modularité et devient de la friction.

C’est la première leçon générale : une frontière qui simplifie la première version peut devenir une taxe à chaque sortie suivante.
Une bonne architecture n’est pas celle qui est élégante aujourd’hui. C’est celle qui reste bon marché sous le changement.

Glide : l’API qui a livré des jeux (et une dette technique)

Glide était une réponse pragmatique à un vrai problème : la fragmentation des API et le support pilote faible et incohérent pour les standards plus larges.
Les développeurs ne cherchaient pas la philosophie. Ils cherchaient des images par seconde et un comportement prévisible sur les machines des consommateurs.
Glide leur a donné une voie directe vers le matériel Voodoo avec moins de surprises.

En termes de fiabilité, Glide réduisait l’entropie. Moins de combinaisons de fonctionnalités API. Moins de pièges de « comportement indéfini ».
Une surface d’attaque réduite signifie moins de chaos. Les développeurs pouvaient optimiser pour une cible et faire confiance à l’expérience utilisateur.

Mais la facture arrive. Les API propriétaires créent une pression de verrouillage, et les marchés finissent par punir le verrouillage quand les alternatives mûrissent.
Une fois que Direct3D et OpenGL ont stabilisé et amélioré leur support, Glide a cessé d’être « l’option sûre » pour devenir « le cas spécial ».
Les cas spéciaux sont là où votre rotation d’on-call va mourir.

Voici la partie inconfortable : Glide n’était pas « faux ». Il était localement optimal. Il a aidé à gagner la guerre initiale.
Le mode d’échec est de ne pas avoir de stratégie de migration crédible quand l’écosystème bouge.
Si votre pari de plateforme est « tout le monde continuera à dépendre de notre couche propriétaire », vous ne construisez pas un fossé — vous construisez un calendrier.

SLI : monter en charge avant que « multi-GPU » ne devienne un slogan marketing

Le SLI de Voodoo2 — scan-line interleave — était une solution astucieuse et très 1998. Scindez la sortie de rendu par lignes horizontales alternées :
la carte A rend un ensemble, la carte B rend l’autre. Vous obtenez plus de fill rate, plus de débit de textures et de meilleures performances à haute résolution.

Du point de vue SRE, SLI est une mise à l’échelle horizontale avec une contrainte brutale : synchronisation parfaite et partition prévisible.
Quand ça marche, c’est beau. Quand ça ne marche pas, vous obtenez des artefacts, des saccades, des bizarreries de pilote et des tickets support écrits EN MAJUSCULES.

Il y a aussi une histoire économique. Les configurations multi-cartes transfèrent le coût vers l’enthousiaste. C’est correct quand les enthousiastes définissent le marché.
C’est moins correct quand les acheteurs grand public veulent une seule carte qui « fonctionne tout simplement », et que les OEM veulent des nomenclatures et des pièces à échouer moindres.

Une vérité sèche : monter en charge en ajoutant plus de la même chose est une stratégie valable jusqu’à ce que la volonté de payer du client atteigne un plafond.
Les entreprises matérielles l’apprennent comme les équipes cloud : votre modèle d’échelle n’est aussi bon que la personne qui signe la facture.

Points de bascule : où la trajectoire s’est infléchie vers le bas

3dfx n’est pas mort parce qu’ils ont cessé d’être intelligents. Ils sont morts parce que le système autour d’eux a évolué plus vite que leur modèle opérationnel.
Quelques changements cumulatifs ont compté :

Le rythme est devenu stratégie. Les concurrents itéraient plus vite. Fonctionnalités, pilotes, cartes — tout allait plus vite.
L’intégration a gagné. Clients et OEM ont préféré des solutions 2D/3D mono-carte avec moins de variables de compatibilité.
Les incitations des développeurs ont changé. Supporter une API propriétaire est acceptable quand ça vous apporte des clients ; c’est pénible quand ça vous apporte des cas limites.
Le conflit de canal est réel. Acheter un fabricant de cartes et vendre vos propres cartes change votre relation avec l’écosystème qui distribuait vos puces.
La pression d’exécution a augmenté. À mesure que la concurrence se resserrait, « presque prêt » devenait « hors-sujet ».

Le piège classique du postmortem est de choisir un seul méchant : « Ils auraient dû faire X. »
La réalité est plus irritante. Ils avaient plusieurs paris imbriqués, chacun défendable, et ensemble ils ont réduit la flexibilité.
En langage de fiabilité : ils ont créé des domaines de défaillance corrélés.

Un principe d’ingénierie notable s’applique ici. Comme le dit Google SRE : « L’espoir n’est pas une stratégie. » — (idée paraphrasée), attribuée à la tradition Google SRE.
Sur les marchés, l’espoir ressemble à supposer que votre avantage actuel persistera pendant que l’environnement se réorganise selon le calendrier d’un concurrent.

Trois mini-récits d’entreprise : hypothèse, effet inverse, victoire ennuyeuse

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (la mentalité « câble pass-through »)

Un studio de jeu de taille moyenne — appelons-le Studio A — avait un titre PC proche de la sortie. Leur objectif de performance interne était basé sur une hypothèse :
« La majorité de nos joueurs aura le chemin rapide activé. » En 1997, cela signifiait un renderer Glide sur une carte Voodoo.

Ils ont optimisé la pipeline artistique et la complexité des scènes autour de ce profil. Ça rendait bien en QA, parce que les machines de QA étaient, sans surprise,
les machines dont l’équipe se souciait : équipées de Voodoo, réglées et bénies par les dieux du matériel neuf.

Puis ils ont expédié. La file de support a flambé avec des joueurs sur des cartes non-3dfx (ou sans accélérateur 3D) signalant des fréquences d’images injouables.
Pas « un peu saccadé ». Injouable. Le chemin de secours Direct3D avait été traité comme une case de compatibilité, pas comme un renderer de première classe.

La réponse à l’incident fut le triage habituel : corriger à chaud les pires cas, réduire les niveaux de détail par défaut et ajouter un assistant d’auto-détection.
Mais le vrai dommage était réputationnel : les critiques ne se soucient pas des raisons pour lesquelles votre chemin de secours est lent. Ils se soucient qu’il soit lent.

La mauvaise hypothèse n’était pas « Voodoo est populaire ». C’était : « Nos clients ressemblent à notre labo. »
3dfx a bénéficié de cette hypothèse au départ, mais à mesure que le paysage matériel s’est diversifié, elle est devenue un handicap pour tous ceux qui se sont construits autour.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (tuning pilote comme maximum local)

Un fabricant de matériel — appelons-le Vendor B — a décidé de courir après des victoires de bench. Pas des victoires en vrai jeu. Des victoires de bench.
Ils ont introduit des optimisations agressives au niveau pilote : heuristiques de cache de textures, raccourcis sur les changements d’état, et quelques hypothèses « utiles » sur le comportement des applis.

Sur des tests synthétiques et une poignée de titres populaires, les performances ont bondi. Le marketing était ravi.
L’optimisation était réelle, mesurable et immédiatement visible dans les tableaux de review. Tout le monde a eu sa dose de dopamine en forme de bonus.

Puis les rapports de bug ont commencé : textures scintillantes, brouillard parfois incorrect, z-fighting qui n’existait pas auparavant.
Ça n’arrivait pas sur toutes les machines. Ça n’arrivait pas à tous les niveaux. Ça arrivait juste assez pour que le support ne puisse pas le reproduire de manière fiable.

L’effet inverse n’est pas « les optimisations sont mauvaises ». L’effet inverse est qu’ils ont optimisé sans garde-fous :
pas de canary rollout, pas de suite de régression haute-fidélité sur une matrice de titres diversifiée, et pas de mécanisme de rollback rapide.
Ils ont troqué la marge de correction pour la vitesse et n’ont pas instrumenté le rayon d’impact.

C’est autant une leçon de marché qu’une leçon d’ingénierie : quand la performance est votre marque, la correction fait partie de la performance.
Une image rapide mais erronée reste erronée. Les joueurs le remarquent. Les développeurs s’en souviennent.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (discipline de livraison)

Un autre studio — Studio C — traitait les chemins de rendu comme des services de production. Ils maintenaient deux renderers principaux (un chemin propriétaire rapide, un API standard)
et imposaient une règle : les deux doivent s’exécuter en CI à chaque commit de contenu.

Ils gardaient des captures dorées par niveau et par renderer. Pas parce que c’était amusant. Parce que ça attrapait tôt les corruptions silencieuses :
une fuite d’état de shader, un mauvais format de texture, un problème de précision du tampon de profondeur qui n’apparaissait que sur une famille de pilotes.

Tard dans le développement, une mise à jour majeure du pilote GPU a changé le comportement autour du filtrage de textures.
Studio C l’a détectée en quelques heures, a produit un repro minimal et a déployé un flag de contournement dans leur patch suivant.
Leur jeu est resté stable tandis que les concurrents bataillaient sur les forums.

La pratique était ennuyeuse : validation automatisée, builds reproductibles et politique « aucun renderer laissé pour compte ».
Ce n’était pas bon pour le marketing. Ça a empêché leur lancement de se transformer en incident public.

Blague #1 : L’évolutivité multi-GPU, c’est comme les projets de groupe — quelqu’un finit toujours par faire tout le travail, et ce n’est jamais la personne à qui on pensait.

Tâches pratiques : 12+ vérifications par commande pour diagnostiquer « le GPU est lent » en conditions réelles

L’histoire de 3dfx porte sur les contraintes : bande passante, stabilité des pilotes, limites du bus et la réalité opérationnelle du matériel hétérogène.
Les systèmes modernes ne sont pas si différents. Remplacez « AGP vs PCI » par « lignes PCIe », remplacez « Glide vs Direct3D » par « Vulkan vs DX12 vs couches de compatibilité »,
et vous finirez par faire le même travail : mesurer, identifier le goulot, changer une chose, mesurer encore.

Ci-dessous des tâches pratiques que vous pouvez exécuter sur des hôtes Linux (configurations gaming, nœuds de rendu, runners CI ou postes de développement).
Chaque tâche inclut la commande, ce que la sortie signifie et quelle décision en découle.

Task 1: Identify the GPU and driver actually in use

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D controller"
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:3282]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Signification : Vous confirmez l’ID du périphérique et quel driver kernel est attaché.
Décision : Si vous attendiez un driver différent (par ex. nouveau vs nvidia), arrêtez et corrigez cela d’abord — tous les autres benchmarks seraient du bruit.

Task 2: Check GPU utilization and throttling clues

cr0x@server:~$ nvidia-smi
Wed Jan 21 10:19:44 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+----------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  GeForce GTX 1060 6GB            Off | 00000000:01:00.0  On |                  N/A |
| 35%   79C    P2              116W / 120W |   5450MiB /  6144MiB |     98%      Default |
+-----------------------------------------+----------------------+----------------------+

Signification : 98% d’utilisation suggère une charge liée au GPU ; 79C et proche du cap de puissance laisse penser à un throttling possible.
Décision : Si l’état de performance est bas (P2/P3) avec une utilisation élevée, vérifiez les clocks et les limites thermiques ; si GPU-Util est bas, vous êtes probablement lié au CPU ou à l’I/O.

Task 3: Verify current clocks (detect thermal or power throttling)

cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,power.draw,power.limit,temperature.gpu --format=csv
clocks.gr [MHz], clocks.mem [MHz], power.draw [W], power.limit [W], temperature.gpu
1708, 4006, 116.21, 120.00, 79

Signification : Clocks proches du boost attendu, puissance proche de la limite. Si les clocks sont bas tandis que la puissance/les températures sont élevées, vous subissez un throttling.
Décision : Améliorez le refroidissement, réduisez la cible de puissance ou acceptez une enveloppe de performance soutenue plus faible. N’essayez pas « d’optimiser le code » pour régler un problème de dissipateur.

Task 4: Confirm PCIe link width and speed (bus bottlenecks are still real)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
LnkSta:	Speed 2.5GT/s (downgraded), Width x4 (downgraded)

Signification : Le slot peut faire x16 à 8GT/s, mais vous êtes en x4 Gen1. C’est un énorme limitateur de performance.
Décision : Reseat la carte, vérifiez les réglages BIOS, déplacez-la dans un autre slot, vérifiez le partage de lignes sur la carte mère (NVMe peut voler des lignes). Mesurez de nouveau après.

Task 5: Determine whether the workload is CPU-bound

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.12 (server) 	01/21/2026 	_x86_64_	(16 CPU)

10:20:01 AM  CPU   %usr %nice  %sys %iowait  %irq  %soft  %steal  %idle
10:20:02 AM  all   82.10  0.00  6.15    0.20  0.00   0.45    0.00  11.10
10:20:02 AM    7   99.00  0.00  0.50    0.00  0.00   0.00    0.00   0.50

Signification : Un cœur collé à ~100% alors que le GPU est sous-utilisé est un goulot classique mono-thread (thread pilote, thread principal du jeu).
Décision : Réduisez le coût des draw-calls, changez les réglages du moteur ou testez un backend API différent. Les upgrades hardware doivent correspondre au goulot, pas à vos espoirs.

Task 6: Catch obvious I/O stalls (asset streaming, shader cache, page faults)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.02    8.55    0.00   50.31

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         120.0   14500.0     0.0   0.00    1.20   120.8     95.0   8900.0    2.10    93.7    0.38   32.0

Signification : L’iowait est non négligeable, mais la latence NVMe est faible ; le disque n’est pas saturé.
Décision : Si %util approche 100% avec un await élevé, vous êtes lié au stockage — déplacez la charge vers du stockage plus rapide ou réduisez le streaming. Sinon, cherchez ailleurs.

Task 7: Check memory pressure and swapping (the silent performance killer)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       550Mi       1.2Gi       2.5Gi       1.6Gi
Swap:           16Gi        6.2Gi       9.8Gi

Signification : Peu de mémoire disponible et swap actif signifie pagination.
Décision : Ajoutez de la RAM, réduisez l’empreinte du workload ou limitez la taille des textures. Ne mesurez pas les performances GPU pendant que l’OS joue aux chaises musicales avec les pages mémoire.

Task 8: Confirm compositor / display server constraints (frame pacing issues)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Signification : Vous êtes sous Wayland ; le comportement diffère de X11 pour certains pilotes et jeux.
Décision : Si vous voyez des saccades ou des problèmes de pacing, testez le même workload sous X11 ou ajustez les paramètres du compositeur. Contrôlez les variables avant de blâmer le GPU.

Task 9: Inspect kernel logs for PCIe or GPU faults

cr0x@server:~$ sudo dmesg -T | tail -n 15
[Wed Jan 21 10:18:22 2026] NVRM: GPU at PCI:0000:01:00: GPU-12345678-90ab-cdef-1234-567890abcdef
[Wed Jan 21 10:18:23 2026] NVRM: Xid (PCI:0000:01:00): 79, pid=22119, name=game.bin, GPU has fallen off the bus.
[Wed Jan 21 10:18:23 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0

Signification : « GPU has fallen off the bus » est un souci de stabilité critique : alimentation, slot, riser ou driver en cause.
Décision : Arrêtez les optimisations et commencez la stabilisation : reseat, vérifiez l’alim, retirez les risers, mettez à jour le BIOS, testez une branche de driver différente. Le travail de performance est inutile tant que les erreurs persistent.

Task 10: Validate OpenGL/Vulkan renderer selection (wrong device happens)

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

Signification : Confirme que l’application touchera probablement le GPU discret pour OpenGL.
Décision : Si cela montre llvmpipe ou un renderer iGPU, corrigez les réglages PRIME/offloading ; sinon vous testez le mauvais périphérique.

Task 11: Inspect Vulkan device enumeration (especially on multi-GPU systems)

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

Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceName         = NVIDIA GeForce GTX 1060 6GB
GPU1:
	apiVersion         = 1.3.275
	driverVersion      = 23.3.1
	vendorID           = 0x1002
	deviceName         = AMD Radeon(TM) Graphics

Signification : Deux GPUs visibles. Les applis peuvent choisir le mauvais par défaut.
Décision : Forcez la sélection du GPU via les paramètres de l’appli ou des variables d’environnement si nécessaire ; confirmez après changements. L’ambiguïté multi-périphérique est la version moderne du « mauvais renderer ».

Task 12: Measure frame time stability, not just average FPS (stutter diagnosis)

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=0.12 avg60=0.08 avg300=0.05 total=2912301
full avg10=0.02 avg60=0.01 avg300=0.00 total=183921

Signification : La pression CPU « full » indique des périodes où les tâches ne pouvaient pas s’exécuter à cause de la contention CPU — cela se manifeste souvent par des saccades.
Décision : Réduisez les services en arrière-plan, isolez des cœurs CPU ou ajustez les priorités du scheduler. Le pacing des images est une propriété end-to-end, pas un chiffre GPU seul.

Task 13: Confirm CPU frequency scaling isn’t sabotaging you

cr0x@server:~$ sudo cpupower frequency-info | sed -n '1,25p'
analyzing CPU 0:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 0
  available frequency steps: 3.40 GHz, 2.80 GHz, 2.20 GHz
  current policy: frequency should be within 2.20 GHz and 3.40 GHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 2.20 GHz (asserted by call to hardware)

Signification : Le governor est sur powersave ; le CPU bloqué à basse fréquence peut créer un goulot CPU qui se fait passer pour une « lenteur GPU ».
Décision : Passez en performance pour les benchmarks ou les workloads sensibles à la latence, puis réévaluez. Ne confondez pas « politique batterie » et « capacité matérielle ».

Task 14: Check for shader cache thrash and filesystem latency

cr0x@server:~$ sudo strace -f -e trace=file -p $(pgrep -n game.bin) 2>&1 | head
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/index", O_RDONLY|O_CLOEXEC) = 42
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/ab/cd/ef...", O_RDONLY|O_CLOEXEC) = 43
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/01/23/45...", O_RDONLY|O_CLOEXEC) = 44

Signification : Le process martèle les fichiers du cache de shaders ; si le stockage est lent ou le cache sur des home directories réseau, vous verrez des saccades.
Décision : Déplacez le cache sur un stockage local rapide, augmentez la taille du cache ou précompilez les shaders. On ne peut pas surpasser un cache froid sur un système de fichiers lent.

Blague #2 : Les mises à jour de pilotes sont comme des migrations de base de données « rapides » — peu importe votre confiance, planifiez-les comme si vous alliez le regretter.

Mode d’emploi pour diagnostic rapide : trouver le goulot en quelques minutes

Quand quelque chose « paraît lent », vous n’êtes pas payé pour admirer la complexité. Vous êtes payé pour isoler rapidement le facteur limitant.
Voici une séquence à fort signal qui fonctionne pour les jeux, les nœuds de rendu et les pipelines accélérés GPU.

First: verify you’re measuring the right device and the right path

Confirmez le GPU et le binding du driver (lspci -nnk).
Confirmez que le renderer est le GPU discret (glxinfo -B, vulkaninfo --summary).
Vérifiez le type de session / compositeur et toutes contraintes connues (echo $XDG_SESSION_TYPE).

Point de décision : Si le mauvais périphérique est sélectionné, corrigez la sélection avant de benchmarker. Sinon vous rédigez de la fiction chiffrée.

Second: decide whether it’s GPU-bound, CPU-bound, or I/O-bound

Utilisation GPU et clocks (nvidia-smi ou équivalent).
Saturation CPU par cœur (mpstat -P ALL).
Latence et utilisation du stockage (iostat -xz).
Pression mémoire et swap (free -h).

Point de décision : Choisissez une classe de goulot et poursuivez-la. Ne « tout optimiser » pas à la fois sauf si votre but est de n’apprendre rien.

Third: eliminate stability issues before performance tuning

Scan des logs kernel pour erreurs PCIe et faults GPU (dmesg -T).
Vérification vitesse/largeur lien PCIe (lspci -vv).

Point de décision : Toute erreur de bus, Xid ou lien dégradé signifie : corrigez hardware/firmware/config d’abord. Optimiser les performances sur une plateforme instable est une perte de temps.

Erreurs courantes : symptômes → cause racine → correction

Symptom: Great average FPS, terrible stutter

Cause racine : Contention CPU (processus en arrière-plan), compilation de shaders pendant le jeu, ou latence système de fichiers pour les caches.

Correction : Vérifiez la pression CPU (/proc/pressure/cpu), déplacez les caches de shaders sur SSD local, précompilez les shaders, limitez les jobs en arrière-plan.

Symptom: GPU “should be fast,” but utilization is low

Cause racine : Goulot mono-thread du CPU, overhead pilote, ou l’appli tourne sur un iGPU/llvmpipe.

Correction : Vérifiez la sélection du renderer (glxinfo -B), surveillez l’utilisation par cœur (mpstat), essayez un backend API différent ou réduisez les draw calls.

Symptom: Sudden performance drop after adding an NVMe drive

Cause racine : Partage de lignes PCIe causant la négociation du GPU en x4 ou Gen1/Gen2.

Correction : Vérifiez LnkSta via lspci -vv, déplacez les périphériques entre les slots, ajustez la configuration des lignes dans le BIOS.

Symptom: Random black screens or “GPU fell off the bus”

Cause racine : Instabilité d’alimentation, mauvais contact riser/slot, VRM en surchauffe, ou incompatibilités driver/kernel.

Correction : Inspectez dmesg, simplifiez le chemin matériel (pas de risers), validez la marge PSU, testez des versions de driver alternatives, mettez à jour le BIOS.

Symptom: “It was faster on the old driver”

Cause racine : Changements de paramètres par défaut (gestion d’énergie, comportement du cache de shaders), régression dans un chemin de code spécifique, ou benchmark non représentatif.

Correction : Comparez clocks/limites de puissance, validez le même workload et les mêmes paramètres, gardez un plan de rollback et maintenez une petite suite de régression.

Symptom: Great performance in one API (e.g., Vulkan), bad in another (e.g., OpenGL)

Cause racine : Différences de maturité des pilotes, différences de qualité des backends moteur, ou couches de compatibilité qui se comportent différemment.

Correction : Choisissez le backend stable pour votre parc ; standardisez-le. Si vous devez supporter les deux, testez-les continuellement (ennuyeux, correct, efficace).

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

Checklist: if you’re restoring a retro 3dfx-era machine (mindset still applies)

Stabilisez la plateforme d’abord : alimentation, refroidissement, contacts propres. La performance vient après « ça ne plante pas ».
Contrôlez les variables : un changement à la fois (version du driver, API, résolution).
Validez le chemin de rendu : assurez-vous que l’API/renderer attendu est sélectionné.
Mesurez le temps de frame, pas seulement le FPS : la fluidité est une métrique de fiabilité.

Checklist: if you’re running modern GPU systems like production services

Inventaire : capturez modèle GPU, version du driver, statut du lien PCIe et version du kernel par hôte.
Baseline : enregistrez un run de benchmark known-good avec clocks, puissance, températures et utilisations.
Garde-fous : canary des mises à jour de drivers sur un sous-ensemble ; exiger readiness de rollback.
Suite de régression : choisissez quelques workloads représentatifs ; automatisez-les.
Télémetrie : logguez les erreurs GPU depuis les logs kernel ; alertez sur les événements récurrents Xid/AER.
Capacity planning : suivez la pression mémoire et le swap ; traitez le swap comme un incident pour les workloads sensibles à la latence.

Step-by-step plan: when a team says “the GPU is slower than last week”

Confirmez le device/chemin driver (Task 1, 10, 11). Si c’est incorrect, corrigez la sélection — ne débattez pas.
Vérifiez les signaux de stabilité (Task 9). Toute erreur bus/GPU signifie que vous êtes en mode incident, pas performance.
Vérifiez la négociation PCIe (Task 4). Les liens dégradés sont courants et dévastateurs.
Classifiez le goulot (Task 2, 5, 6, 7). Choisissez la contrainte dominante.
Vérifiez les réglages politiques (Task 13). Gouverneurs et limites de puissance peuvent ressembler à des « régressions ».
Ce n’est qu’ensuite que vous commencez l’optimisation au niveau code ou moteur.

FAQ

3dfx était-elle condamnée dès l’arrivée de NVIDIA ?

Non. La concurrence ne vous condamne pas ; l’inflexibilité le fait. NVIDIA a exécuté plus vite et a surfé sur l’intégration et les standards, mais 3dfx avait encore des options — juste de moins en moins.

Pourquoi Glide a-t-il compté autant ?

Il a donné aux développeurs une cible stable dans une époque instable. Cette stabilité a créé une boucle vertueuse : plus de jeux supportaient Glide, plus de gens achetaient des cartes Voodoo, etc.
Le coût stratégique ultérieur était évident : les chemins propriétaires vieillissent mal quand les standards rattrapent.

Le SLI était-il vraiment une bonne ingénierie ?

Pour son époque, oui. C’était une approche d’échelle intelligente sous contrainte. La leçon plus large est que l’évolutivité ajoute de la complexité,
et la complexité devient un fardeau de support quand vous essayez de devenir grand public.

L’achat d’un fabricant de cartes a-t-il aidé 3dfx ?

L’intégration verticale peut améliorer le contrôle et les marges, mais ça peut aussi aliéner des partenaires qui vendaient auparavant vos puces.
Si votre écosystème de distribution est un multiplicateur de force, choisir de l’affronter est… audacieux.

Quel est l’équivalent moderne du piège Glide ?

Toute couche propriétaire que les développeurs adoptent parce que c’est la seule voie fiable — jusqu’à ce que ce ne le soit plus.
Si vous possédez une telle couche, vous avez besoin d’une histoire de migration avant que le marché ne l’impose.

Comment éviter le « benchmark engineering » qui se retourne contre vous ?

Traitez la correction comme faisant partie de la performance. Construisez des tests de régression qui rendent des workloads réels, pas seulement des graphiques synthétiques.
Déployez les changements de pilote/optimisation en canary et prévoyez un rollback rapide.

Quelle métrique unique suivriez-vous si vous gérez des flottes GPU ?

Les taux d’erreur et les signaux de stabilité d’abord (faults GPU kernel, erreurs PCIe). La performance vient après la fiabilité.
Un GPU qui « disparaît parfois » a une latence infinie.

Quel est le premier contrôle quand un GPU sous-performe ?

Le statut du lien PCIe et la sélection du device. Une carte en x4 Gen1 ou l’appli s’exécutant sur un iGPU peuvent imiter une douzaine d’autres problèmes.

3dfx a-t-elle perdu parce qu’ils manquaient de meilleur matériel ?

Le matériel compte, mais le modèle opérationnel compte plus : cadence, pilotes, support plateforme, écosystème partenaire et adaptabilité stratégique.
Vous pouvez livrer une excellente puce et perdre quand même le jeu système.

Conclusion : étapes pratiques suivantes

3dfx reste dans les mémoires pour les cartes Voodoo et le moment où les jeux PC ont cessé de ressembler à des tableaux avec de l’attitude.
Mais la partie utile de l’histoire n’est pas la nostalgie — ce sont les modes d’échec.
Ils ont gagné tôt en restreignant le périmètre et en rendant le chemin chaud ultra-rapide. Ils ont perdu plus tard en conservant des choix devenus coûteux sous le changement :
dépendances propriétaires, friction dans l’écosystème et adaptation plus lente à l’intégration et au rythme.

Si vous construisez des plateformes — matériel, pilotes, API ou même infrastructure interne — les prochaines étapes sont franches :

Mesurez la réalité, pas l’intention. Inventoriez ce qui est réellement déployé et quels chemins de code sont réellement utilisés.
Stabilisez d’abord. Toute erreur de bus, crash de driver ou condition de dégradation transforme le travail de performance en distraction.
Concevez la migration. Si vous offrez un « chemin rapide » propriétaire, planifiez la rampe de sortie avant que le marché ne l’exige.
Appliquez la discipline ennuyeuse. Suites de régression, canaries, plans de rollback — ce sont des avantages compétitifs déguisés en corvées.