Si vous avez déjà essayé de « simplement ajouter une autre GPU » en vous attendant à voir la courbe monter sans accroc, vous avez déjà rencontré le méchant de cette histoire : le monde réel. Le multi-GPU grand public — NVIDIA SLI et AMD CrossFire — ressemblait à une pure vertu d’ingénierie : parallélisme, plus de silicium, plus d’images, terminé.
Puis vous l’avez livré. Les temps de trame se sont transformés en grille irrégulière. La pile de pilotes est devenue une négociation entre moteur de jeu, ordonnanceur GPU, PCIe et la synchronisation d’affichage que vous croyiez comprendre. Votre seconde carte chère devenait souvent un radiateur d’appoint avec un CV.
La promesse : monter en puissance en ajoutant des GPU
Le multi-GPU, tel qu’il était vendu aux joueurs, était un conte opérationnel : votre jeu est limité par le GPU, donc un GPU de plus signifie presque le double de performance. C’est le pitch. C’est aussi la première hypothèse erronée. Les systèmes ne montent pas en charge parce qu’une diapositive marketing dit « 2× » ; un système évolue quand la partie la plus lente de la chaîne cesse d’être le goulot d’étranglement.
Une image de jeu moderne est une chaîne de montage chaotique : simulation CPU, soumission d’appels de dessin, rendu GPU, post-traitement, composition, présentation et un contrat de timing avec votre affichage. SLI/CrossFire a essayé de masquer la complexité du multi-GPU derrière des pilotes, des profils et un pont. C’est précisément ce masquage qui l’a condamné.
Le rêve du multi-GPU est mort parce qu’il s’est heurté à la physique (latence et synchronisation), à l’économie logicielle (les développeurs ne testent pas les configs rares) et aux changements de plateforme (DX12/Vulkan ont déplacé la responsabilité du pilote vers le moteur). Et parce que la « moyenne FPS » s’est révélée être un mensonge par omission : ce que vos yeux perçoivent, c’est la régularité des temps de trame, pas la moyenne.
Comment SLI/CrossFire fonctionnait réellement
Multi-GPU géré par le pilote : des profils partout
À l’époque classique, SLI/CrossFire reposait sur des heuristiques de pilote et des profils par jeu. Le pilote décidait comment répartir le rendu entre les GPU sans que le jeu le sache explicitement. Ça semble pratique. C’est aussi un cauchemar opérationnel : vous avez maintenant un système distribué où un nœud (le jeu) ne sait pas qu’il est distribué.
Les profils étaient cruciaux parce que la plupart des jeux n’étaient pas écrits pour être parallélisés en toute sécurité entre GPU. Le pilote avait besoin d’« indices » spécifiques au jeu pour éviter des risques comme lire des données qui n’avaient pas encore été produites, ou appliquer un post-traitement qui suppose l’historique complet d’une image.
Les modes principaux : AFR, SFR et « s’il vous plaît, ne faites pas ça »
Alternate Frame Rendering (AFR) était le cheval de bataille. Le GPU0 rend la trame N, le GPU1 rend la trame N+1, etc. Sur le papier : fantastique. En pratique : AFR est une machine à latence et à pacing. Si la trame N prend 8 ms et la trame N+1 prend 22 ms, votre « FPS moyen » peut sembler correct alors que vos yeux subissent un diaporama saccadé.
Split Frame Rendering (SFR) divise une trame en régions. Cela exige un équilibrage de charge soigné : une moitié de l’écran peut contenir une explosion, des shaders de cheveux, des volumétriques et vos regrets ; l’autre moitié est un mur. Devinez quel GPU finit en premier et reste inactif.
Il y avait aussi des modes hybrides et des astuces spécifiques aux fabricants. Plus vous avez besoin de hacks, moins la solution est générale. À un moment donné, vous n’êtes plus en train de « prendre en charge le multi-GPU » ; vous écrivez une réponse incidente par titre au niveau du pilote.
Ponts, PCIe et pourquoi l’interconnexion n’a jamais été le héros
Les ponts SLI (et les ponts CrossFire dans les premières époques) fournissaient un chemin à plus large bande passante et plus faible latence pour certaines opérations de synchronisation et de partage de tampons que le PCIe seul. Mais le pont ne fusionnait pas magiquement la VRAM. Chaque GPU gardait sa mémoire propre. En AFR, chaque GPU avait typiquement besoin de sa propre copie des mêmes textures et géométries. Donc vos « deux cartes 8 Go » ne devenaient pas « 16 Go ». Elles restaient « 8 Go, en double ».
Lorsque les développeurs ont commencé à s’appuyer davantage sur des techniques temporelles — TAA, réflexions en espace-écran avec buffers d’historique, sur-échantillonneurs temporels — AFR est devenu de plus en plus incompatible. Vous ne pouvez pas facilement rendre la trame N+1 sur le GPU1 si elle a besoin de l’historique de la trame N qui vit sur le GPU0, à moins d’ajouter de la synchronisation et des transferts de données qui effacent le gain de performance.
Une idée paraphrasée, largement attribuée à l’esprit de la fiabilité des systèmes (et souvent prononcée par des ingénieurs dans l’orbite SRE de Google) : L’espoir n’est pas une stratégie.
Elle colle parfaitement au multi-GPU. SLI/CrossFire vous demandait d’espérer que le pipeline de rendu de votre jeu s’aligne sur les hypothèses du pilote.
Pourquoi ça a échoué : la mort par mille cas limites
1) Le pacing des images a tué le « ressenti »
AFR peut fournir un FPS moyen élevé tout en produisant des temps de trame inégaux (micro-saccades). Les humains remarquent la variance. Votre overlay peut afficher « 120 FPS », tandis que votre cerveau enregistre « irrégulier ». C’était l’échec central de l’expérience utilisateur : SLI/CrossFire pouvait gagner des benchmarks et perdre l’impression de fluidité.
Le pacing des images n’est pas juste « un petit jitter ». Il interagit avec le VSync, le VRR (G-SYNC/FreeSync), la profondeur de la file de rendu et l’ordonnancement CPU. Si le pilote met trop agressivement en file des images, vous obtenez de la latence d’entrée. S’il en met trop peu, vous avez des bulles et du stutter.
Blague #1 : Le multi-GPU, c’est comme avoir deux stagiaires écrivant alternativement des pages du même rapport — rapide, jusqu’au moment où vous constatez qu’ils ne s’entendent pas sur l’intrigue.
2) Mirroring de la VRAM : vous payiez pour de la mémoire inutilisable
Le multi-GPU grand public répliquait presque toujours les ressources dans la mémoire de chaque GPU. Cela permettait de scaler sans traiter la mémoire comme un pool cohérent partagé, mais cela signifiait aussi que les textures haute résolution, la géométrie volumineuse et les structures d’accélération modernes pour le ray tracing étaient limitées par la VRAM d’une seule carte.
À mesure que les jeux devenaient plus gourmands en VRAM, le plan « ajoutez une seconde GPU » empirait : votre goulot d’étranglement passait du calcul à la capacité mémoire, et le multi-GPU n’aidait pas. Pire encore, une seconde GPU augmentait la consommation électrique, la chaleur et les besoins d’aération du boîtier tout en conservant la même limite de VRAM qu’une seule carte.
3) Le CPU est devenu le coordinateur, et lui non plus n’a pas monté en charge
Le multi-GPU n’est pas seulement « deux GPU ». C’est du travail supplémentaire pour le pilote, plus de gestion de tampons de commandes, plus de synchronisation et souvent plus d’appels de dessin. Beaucoup de moteurs étaient déjà limités par le CPU sur le thread de rendu. Ajouter un second GPU peut déplacer le goulot d’étranglement en amont et faire du CPU le facteur limitant.
En termes de production : vous avez ajouté de la capacité à un service aval sans augmenter le débit en amont. Félicitations, vous avez inventé une nouvelle file d’attente.
4) Le modèle de profils pilotes n’a pas survécu à la chaîne d’approvisionnement logicielle
SLI/CrossFire géré par le pilote exigeait que les vendeurs suivent les nouvelles sorties de jeux, les correctifs, les mises à jour de moteurs et les nouvelles techniques de rendu. Les studios livraient des mises à jour hebdomadaires. Les fournisseurs de GPU sortaient des pilotes à un rythme plus lent et devaient tester des milliers de combinaisons.
Un profil multi-GPU qui fonctionne en version 1.0 peut casser en 1.0.3 parce qu’un post-traitement a changé d’ordre, ou parce qu’un nouveau filtre temporel lit maintenant un tampon d’une trame précédente. Le pilote « optimisant » aveuglément peut devenir la chose qui corrompt l’image.
5) Le VRR (taux de rafraîchissement variable) et le multi-GPU se sont mis des bâtons dans les roues
Le taux de rafraîchissement variable est une des meilleures améliorations de qualité de vie pour le jeu PC. Il complique aussi le pacing multi-GPU : l’écran s’adapte au rythme de livraison des images, donc si AFR crée des rafales et des creux, le VRR ne peut pas « lisser » cela ; il va montrer fidèlement l’irrégularité.
Beaucoup d’utilisateurs ont acheté des écrans VRR et ont découvert que leur configuration multi-GPU auparavant « correcte » semblait maintenant pire. Ce n’est pas la faute de l’écran. C’est que vous voyez enfin la vérité.
6) Le multi-GPU explicite est arrivé, et l’industrie n’a pas voulu payer la facture
DX12 et Vulkan ont rendu possible le multi-adapter explicite : le moteur peut contrôler plusieurs GPU directement. C’est techniquement plus propre que la magie du pilote. C’est aussi un travail d’ingénierie coûteux qui bénéficie à une infime fraction des clients.
Les studios ont priorisé des fonctionnalités qui s’adressent à tout le monde : meilleurs sur-échantillonneurs temporels, meilleur anti-aliasing, meilleures chaînes de contenu, parité console. Le multi-GPU était une charge de support avec un faible ROI. Il est mort comme beaucoup de fonctionnalités d’entreprise : silencieusement, parce que personne n’a financé la rotation d’astreinte.
7) Puissance, thermique et contraintes du boîtier : la couche physique a résisté
Deux GPU haut de gamme exigent une réelle marge sur l’alimentation, une bonne circulation d’air et souvent une carte mère capable de fournir suffisamment de lanes PCIe sans throttle. La configuration « boîtier grand public + deux GPU flagship » est un projet d’ingénierie thermique. Et la plupart des gens voulaient un ordinateur, pas un hobby qui brûle la poussière.
8) Sécurité et stabilité : la pile pilote est devenue un plus grand périmètre de défaillance
Plus la logique d’ordonnancement du pilote et de synchronisation inter-GPU est complexe, plus il y a de modes de défaillance : écrans noirs, TDR (timeout detection and recovery), corruptions étranges, plantages spécifiques à un jeu. En termes d’exploitation, vous avez augmenté la complexité système et réduit le temps moyen pour innocenter une hypothèse.
Blague #2 : SLI promettait « deux fois plus de GPU », mais parfois livrait « deux fois plus de dépannage », ce qui n’est la caractéristique que personne ne mesure en benchmark.
Contexte historique : les faits que l’on oublie
- Fait 1 : Le nom original « SLI » venait de Scan-Line Interleave de 3dfx à la fin des années 1990 ; NVIDIA a réutilisé l’acronyme plus tard avec une approche technique différente.
- Fait 2 : Le multi-GPU grand public s’est souvent appuyé lourdement sur l’AFR parce que c’était le moyen le plus simple de monter en charge sans réécrire les moteurs.
- Fait 3 : L’évolutivité multi-GPU était notoirement incohérente : certains titres voyaient des gains presque linéaires, d’autres zéro, et certains devenaient plus lents à cause du surcoût CPU/pilote.
- Fait 4 : Les « micro-saccades » sont devenues une plainte grand public au début des années 2010 quand les testeurs ont commencé à mesurer les temps de trame plutôt que le FPS moyen.
- Fait 5 : AMD a investi dans des améliorations de pacing dans ses pilotes après de nombreuses critiques ; cela a aidé, mais n’a pas changé les contraintes fondamentales de l’AFR.
- Fait 6 : De nombreux moteurs ont de plus en plus utilisé des buffers d’historique temporels (TAA, upscalers temporels, vecteurs de mouvement), intrinsèquement peu compatibles avec l’AFR.
- Fait 7 : La bande passante PCIe a augmenté au fil des générations, mais la latence et le surcoût de synchronisation sont restés des problèmes centraux pour les dépendances trame-à-trame.
- Fait 8 : Le multi-GPU explicite DX12/Vulkan donne le contrôle à l’application ; la plupart des studios ont choisi de ne pas l’implémenter car la matrice de tests explosait.
- Fait 9 : NVIDIA a progressivement restreint/modifié le support SLI dans les générations récentes, en se concentrant sur les segments haut de gamme et des cas d’usage spécifiques plutôt que sur un support large des jeux.
Ce qui l’a remplacé (à sa manière) : multi-GPU explicite et alternatives modernes
Multi-GPU explicite : meilleure architecture, pire économie
Le multi-GPU explicite (multi-adapter DX12, device groups Vulkan) est la façon dont vous le concevriez si vous étiez sobre : le moteur sait quelles charges peuvent tourner sur quel GPU, quelles données doivent être partagées et quand synchroniser. Cela enlève beaucoup de suppositions côté pilote.
Cela exige aussi que le moteur soit structuré pour le parallélisme entre dispositifs : duplication des ressources, barrières inter-dispositifs, gestion soignée des effets temporels et stratégies différentes pour différentes combinaisons de GPU. Ce n’est pas « prendre en charge SLI ». C’est construire un second moteur de rendu.
Quelques titres ont expérimenté. La plupart des studios ont fait le calcul et ont acheté autre chose : upscalers temporels, meilleur threading CPU et optimisations de contenu qui aident tous les utilisateurs.
Le « multi-GPU » moderne qui fonctionne réellement : la spécialisation
Le multi-GPU est vivant là où la charge de travail est naturellement parallèle et ne nécessite pas de cohérence stricte trame-à-trame :
- Rendu hors-ligne / path tracing : vous pouvez répartir échantillons ou tuiles entre GPU et fusionner les résultats.
- Calcul / entraînement ML : parallélisme de données avec des frameworks explicites, bien que toujours plein de douleurs de synchronisation.
- Chaînes d’encodage vidéo : des GPU séparés peuvent gérer des flux ou des étapes distinctes.
Pour le jeu en temps réel, la stratégie gagnante est devenue : un GPU puissant, un meilleur ordonnancement, un meilleur upscaling et de meilleures techniques de génération d’images. Pas parce que c’est « cool », mais parce que c’est opérationnellement sensé.
Mode d’emploi pour un diagnostic rapide
Quand quelqu’un dit « mon second GPU ne sert à rien » ou « SLI a empiré les choses », ne commencez pas par des basculements mystiques du pilote. Traitez-le comme un incident. Établissez ce qui est goulot d’étranglement, puis isolez.
Première étape : confirmez que le système voit les deux GPU et que le lien est sain
- Les deux dispositifs sont-ils présents sur le PCIe ?
- Fonctionnent-ils à la génération/largeur PCIe attendue ?
- Le bon pont est-il installé (si nécessaire) ?
- Les connecteurs d’alimentation sont-ils corrects et stables ?
Deuxième étape : confirmez que le chemin logiciel est vraiment multi-GPU
- Le jeu est-il connu pour supporter SLI/CrossFire pour votre génération GPU ?
- Le profil pilote est-il présent/activé ?
- Le chemin API (DX11 vs DX12 vs Vulkan) est-il compatible avec le mode multi-GPU du fournisseur ?
Troisième étape : mesurez les temps de trame et identifiez la ressource limitante
- Utilisation GPU par carte (pas seulement « total »).
- Saturation du thread de rendu CPU.
- Utilisation de la VRAM et comportement de pagination.
- Pacing des images (percentile 99 du temps de trame), pas seulement le FPS moyen.
Quatrième étape : retirez les variables jusqu’à ce que le comportement soit explicable
- Désactivez VRR/VSync temporairement pour observer le pacing brut.
- Testez un titre/benchmark connu pour son bon scaling documenté.
- Testez chaque GPU individuellement pour éliminer une carte marginale.
Tâches pratiques : commandes, sorties et décisions
Ces commandes supposent une station Linux utilisée pour les tests/CI, la reproduction en labo, ou simplement parce que vous aimez la douleur reproductible. Le point n’est pas que Linux soit l’apogée du multi-GPU en jeu ; c’est que Linux vous offre de l’observabilité sans chasse au trésor GUI.
Task 1: List GPUs and confirm the PCIe topology
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
Ce que cela signifie : Deux GPU sont énumérés sur le bus PCIe. Si vous n’en voyez qu’un, arrêtez : vous avez un problème matériel/firmware.
Décision : Si un GPU manque, resseyez-le, vérifiez les alimentations, les réglages du BIOS (Above 4G decoding, config des slots PCIe), puis retestez.
Task 2: Verify PCIe link width and generation for each GPU
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 8GT/s, Width x16
LnkSta: Speed 8GT/s, Width x16
Ce que cela signifie : Le GPU négocie PCIe Gen3 x16 comme attendu. Si vous voyez x8 ou Gen1, vous avez trouvé un goulot ou une régression.
Décision : Si le lien est rétrogradé, vérifiez le câblage des slots, le partage de lanes de la carte mère (M.2 prenant des lanes), le BIOS, les risers et l’intégrité du signal.
Task 3: Confirm NVIDIA driver sees both GPUs and reports utilization
cr0x@server:~$ nvidia-smi -L
GPU 0: GeForce GTX 1080 Ti (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
GPU 1: GeForce GTX 1080 Ti (UUID: GPU-ffffffff-1111-2222-3333-444444444444)
Ce que cela signifie : La couche pilote voit les deux dispositifs. Si l’un manque ici mais est présent dans lspci, vous avez probablement un problème d’association pilote/firmware.
Décision : Si manquant, vérifiez dmesg pour des erreurs GPU, confirmez les modules du noyau et que les deux GPU sont supportés par le pilote installé.
Task 4: Watch per-GPU utilization and memory during load
cr0x@server:~$ nvidia-smi dmon -s pucvmet
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk pviol rxpci txpci
0 210 78 - 92 55 0 0 5500 1582 0 120 110
1 95 64 - 18 52 0 0 5500 1582 0 40 35
Ce que cela signifie : GPU0 fait le gros du travail ; GPU1 est en grande partie inactif mais occupe une VRAM similaire (miroir des assets). C’est le comportement classique du « second GPU non utilisé ».
Décision : Si GPU1 reste au repos, vérifiez que le chemin applicatif prend en charge le multi-GPU ; sinon, cessez d’essayer de réparer une non-fonctionnalité.
Task 5: Confirm Xorg/Wayland session details (to avoid compositor surprises)
cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
Ce que cela signifie : Vous êtes sur Wayland. Certains outils et certains chemins multi-GPU hérités se comportent différemment sous Wayland vs Xorg.
Décision : Si vous déboguez des problèmes de rendu/presentation, reproduisez sous Xorg comme témoin pour isoler les effets du compositeur.
Task 6: Check kernel logs for PCIe errors and GPU resets
cr0x@server:~$ sudo dmesg -T | egrep -i 'pcie|aer|nvrm|gpu|xid' | tail -n 12
[Mon Jan 13 10:19:22 2026] NVRM: Xid (PCI:0000:02:00): 79, GPU has fallen off the bus.
[Mon Jan 13 10:19:22 2026] pcieport 0000:00:03.1: AER: Corrected error received: 0000:02:00.0
Ce que cela signifie : « Fallen off the bus » indique souvent une instabilité d’alimentation/thermique, un riser défaillant, un slot capricieux ou des problèmes d’intégrité du signal — le multi-GPU rend cela plus probable.
Décision : Traitez cela comme de la fiabilité matérielle : réduisez la limite de puissance, améliorez le refroidissement, resseyez, changez de slot, retirez les risers, mettez à jour le BIOS et retestez la stabilité avant d’accuser les pilotes.
Task 7: Check CPU bottleneck indicators (load, run queue, throttling)
cr0x@server:~$ uptime
10:22:11 up 3 days, 6:41, 1 user, load average: 14.82, 13.97, 12.10
Ce que cela signifie : Une charge moyenne élevée peut indiquer une saturation CPU ou des threads exécutables qui s’accumulent. Les jeux peuvent être limités par le CPU sur un seul thread de rendu même si le total CPU n’est pas à « 100% ».
Décision : Si la charge est élevée et que l’utilisation GPU est faible, arrêtez de chercher des réglages SLI. Réduisez les paramètres gourmands CPU (distance de vue, densité de foule), ou acceptez que vous êtes limité par le CPU.
Task 8: Inspect per-core usage to catch a pegged render thread
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (16 CPU)
10:22:18 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:22:19 AM all 42.0 0.0 8.0 0.2 0.0 0.5 0.0 0.0 0.0 49.3
10:22:19 AM 3 98.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.5
Ce que cela signifie : Un cœur (CPU3) est saturé. C’est votre goulot de rendu/jeu. Deux GPU n’aideront pas si la trame ne peut être fournie.
Décision : Réduisez les paramètres liés au CPU, ou passez à une plateforme/CPU avec un meilleur comportement mono‑thread. Le multi-GPU ne résoudra pas un tuyau amont étroit.
Task 9: Verify memory pressure (paging can masquerade as “GPU stutter”)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 30Gi 500Mi 1.2Gi 1.5Gi 1.0Gi
Swap: 16Gi 10Gi 6.0Gi
Ce que cela signifie : Vous swappez beaucoup. Cela détruira les temps de trame quel que soit le nombre de GPU empilés.
Décision : Réglez la pression mémoire d’abord : fermez les applis en arrière-plan, réduisez les paramètres de texture, ajoutez de la RAM et retestez. Traitez l’utilisation du swap comme une alerte critique pour le pacing.
Task 10: Confirm CPU frequency and throttling status
cr0x@server:~$ lscpu | egrep -i 'model name|cpu mhz'
Model name: AMD Ryzen 9 5950X 16-Core Processor
CPU MHz: 3599.998
Ce que cela signifie : La fréquence actuelle est affichée, mais pas si elle est throttlée sous charge soutenue.
Décision : Si les clocks chutent sous charge de jeu, rectifiez le refroidissement ou les limites d’alimentation. Le multi-GPU augmente la chaleur du boîtier, ce qui peut réduire silencieusement le boost CPU.
Task 11: Check power capping / throttling flags on NVIDIA
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i 'Power Limit|Clocks Throttle Reasons' -A3
Power Limit : 250.00 W
Clocks Throttle Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Active
Ce que cela signifie : Le GPU atteint une limite de puissance logicielle. En configuration multi-GPU, les PSU et les VRM thermiques peuvent forcer des limites conservatrices.
Décision : Si le plafonnement de puissance est actif et que la performance est incohérente, considérez réduire l’objectif FPS, améliorer le flux d’air ou faire tourner un seul GPU à des clocks soutenus plus élevés.
Task 12: Check PCIe lane sharing hints from NVLink/bridge status (when available)
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity
GPU0 X PHB 0-7
GPU1 PHB X 8-15
Ce que cela signifie : PHB indique que la communication passe par le pont hôte PCIe ; ce n’est pas un chemin pair-à-pair serré. Cela peut pénaliser toute charge ayant besoin de trafic inter-GPU.
Décision : Si la topologie est mauvaise, cessez d’attendre que la collaboration inter-GPU soit bon marché. Préférez le rendu sur un seul GPU ou une partition explicite des tâches évitant le partage.
Task 13: Confirm Vulkan device visibility (for explicit multi-GPU experiments)
cr0x@server:~$ vulkaninfo --summary | egrep -i 'GPU id|deviceName' -A1
GPU id : 0 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
GPU id : 1 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
Ce que cela signifie : Vulkan voit les deux dispositifs. C’est un prérequis pour les applis multi-GPU explicites, pas une garantie qu’un jeu le supporte.
Décision : Si un seul apparaît, corrigez l’installation du pilote/runtime. Si les deux apparaissent, passez aux vérifications au niveau applicatif des capacités.
Task 14: Validate storage latency (yes, it can look like “GPU stutter”)
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
38.12 0.00 6.21 8.93 0.00 46.74
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 210.0 38400.0 0.0 0.00 3.10 182.86 75.0 10240.0 9.80 2.10 78.00
Ce que cela signifie : Un iowait élevé et des temps d’attente relevés peuvent causer des hitchs de streaming. Le multi-GPU ne corrigera pas des stalls dus à la compilation de shaders ou à la latence de streaming d’assets.
Décision : Si le stockage est saturé, réduisez les IO en arrière-plan, déplacez le jeu vers un stockage plus rapide et traitez le comportement du cache de shaders. Corrigez le vrai goulot d’étranglement.
Erreurs courantes (symptômes → cause → solution)
1) « Le second GPU affiche 0–10% d’utilisation »
Symptômes : Un GPU chauffe, l’autre reste au repos ; FPS identique à un seul GPU.
Cause : Le chemin jeu/API ne prend pas en charge le multi-GPU géré par pilote, ou le profil pilote est manquant/désactivé.
Solution : Validez le support du titre pour votre génération GPU et le mode API. Si le jeu est en DX12/Vulkan et n’implémente pas le multi-GPU explicite, acceptez le single GPU.
2) « FPS moyen plus élevé, mais ça semble pire »
Symptômes : Le benchmark indique un gain ; le jeu semble saccadé ; le VRR rend cela plus visible.
Cause : Variance des temps de trame en AFR (micro-saccades), mise en file ou charge incohérente par trame.
Solution : Mesurez les temps de trame et limitez le FPS pour stabiliser le pacing, ou désactivez le multi-GPU. Priorisez les 1% low / percentile 99 du temps de trame plutôt que les moyennes.
3) « Les textures popent, puis les hitchs deviennent brutaux en 4K »
Symptômes : Pics soudains, surtout en pivotant rapidement ou en entrant dans de nouvelles zones.
Cause : La limite de VRAM est par GPU ; le mirroring fait que vous n’avez pas gagné en capacité. Vous paginez des assets et vous vous bloquez.
Solution : Baissez la résolution des textures, réduisez les réglages RT, ou passez à un seul GPU avec plus de VRAM.
4) « Écrans noirs aléatoires / GPU disparu »
Symptômes : Reset du pilote, un GPU disparaît du bus, instabilités intermittentes.
Cause : Instabilité de l’alimentation, stress thermique, intégrité marginale du signal PCIe, ou un overclock « stable » sur une carte qui ne l’est plus en duo.
Solution : Revenez aux clocks stock, réduisez la limite de puissance, améliorez le refroidissement, vérifiez le câblage, évitez les risers, mettez à jour le BIOS et testez chaque GPU seul.
5) « Ça marchait sur une version de pilote, puis ça casse avec la suivante »
Symptômes : Le scaling disparaît ou des artefacts apparaissent après une mise à jour pilote.
Cause : Changements de profil, modifications d’ordonnancement ou régression dans les chemins multi-GPU (désormais peu prioritaires).
Solution : Verrouillez les versions de pilotes pour votre cas d’usage, documentez les combinaisons connues bonnes et ne considérez pas « dernier pilote » comme nécessairement meilleur pour le multi-GPU.
6) « Deux GPU, mais l’utilisation CPU semble faible — pourtant CPU-bound »
Symptômes : Utilisation GPU faible, FPS plafonné, CPU total sous 50%.
Cause : Un ou deux threads chauds (thread de rendu, thread de jeu). Le total CPU masque la saturation par cœur.
Solution : Observez l’utilisation par cœur. Réduisez les paramètres lourds CPU ; visez des temps de trame stables ; envisagez une montée de plateforme plutôt que d’ajouter des GPU.
7) « PCIe en x8/x4 inattendu, scaling médiocre »
Symptômes : Scaling pire que prévu ; stutter élevé pendant le streaming ; topo montre des chemins PHB.
Cause : Partage de lanes avec M.2/autres dispositifs, mauvais choix de slot ou limitations du chipset uplink.
Solution : Utilisez les slots corrects, réduisez les consommateurs de lanes ou choisissez une plateforme avec plus de lanes CPU si vous insistez sur les configurations multi-dispositifs.
Trois mini-récits d’entreprise depuis le terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Un petit studio disposait d’un « labo performance » avec quelques rigs de test haut de gamme. Quelqu’un avait monté une machine monstrueuse : deux GPU haut de gamme, beaucoup de RGB, et un tableau de chiffres de benchmark qui réjouissait la direction. Le studio l’utilisait pour valider les budgets de performance d’un nouveau niveau riche en contenu.
L’hypothèse erronée était subtile : ils ont supposé que le scaling était représentatif. Leur machine d’approbation fonctionnait en AFR avec un profil pilote qui, par hasard, fonctionnait bien pour cette build spécifique. Elle donnait d’excellents FPS moyens en labo. Elle ne produisait pas de bons temps de trame sur la plupart des machines clients, et elle ne représentait certainement pas la base single-GPU que la majorité possédait.
La semaine de sortie est arrivée. Les réseaux sociaux se sont remplis de plaintes « saccades dans le nouveau niveau ». En interne, le rig labo semblait « correct ». Les ingénieurs ont commencé à chasser des bugs fantômes dans l’animation et la physique parce que les graphiques GPU ne semblaient pas saturés.
Le vrai coupable était le streaming d’assets et un nouvel effet temporel. Sur le rig labo, l’AFR masquait du temps GPU en recouvrant les opérations, tout en dégradant le pacing d’une manière que le studio ne mesurait pas. Sur les config single-GPU des consommateurs, le même effet poussait la VRAM au-delà du seuil et déclenchait de la pagination et du thrash du cache de shaders. Le studio avait optimisé pour la mauvaise réalité.
La solution n’a pas été un tweak multi-GPU magique. Ils ont reconstruit leur gate perf : single-GPU, basés sur les temps de trame, avec des seuils de pression mémoire. Le rig double GPU est resté en labo, mais il a cessé d’être la source de vérité. L’incident s’est terminé quand ils ont arrêté de faire confiance à un benchmark qui ne correspondait pas à la population d’utilisateurs.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une équipe de visualisation entreprise (imaginez : grandes scènes CAO, walkthroughs temps réel) a essayé d’« obtenir des performances gratuites » en activant l’AFR dans un environnement contrôlé. Leurs scènes reposaient fortement sur l’accumulation temporelle : anti-aliasing, débruitage et beaucoup de logique « utiliser la trame précédente ». Quelqu’un a argué que puisque les GPU étaient identiques, les résultats devraient être cohérents.
Ils ont obtenu un débit moyen plus élevé avec une caméra statique. Belle démo. Puis ils ont envoyé une beta à quelques parties prenantes internes. Dès que vous bougiez la caméra, la stabilité de l’image se dégradait : ghosting, scintillement et filtres temporels incohérents. Pire, la latence interactive semblait plus importante parce que la profondeur de file augmentait sous AFR.
Le retour de bâton était architectural : le pipeline temporel du renderer supposait un historique de trame cohérent. AFR a scindé cet historique entre dispositifs. L’équipe a ajouté des points de sync et des transferts cross-GPU pour « corriger » cela, ce qui a détruit le gain de performance et introduit de nouveaux stalls. Désormais, ils avaient de la complexité et aucun gain.
Ils ont fini par retirer l’AFR et investir dans une série d’améliorations ennuyeuses : culling côté CPU, simplification des shaders et règles de LOD de contenu. Le système final était plus rapide sur un seul GPU que la build AFR sur deux. L’optimisation a échoué parce qu’elle optimisait le mauvais niveau : elle a voulu paralléliser quelque chose de fondamentalement sériel en dépendance temporelle.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Un groupe de validation hardware dans une société de taille moyenne maintenait une flotte de nœuds de test GPU. Ils ne jouaient pas dessus ; ils exécutaient des régressions de rendu et de calcul et reproduisaient de temps en temps des bugs clients. Les nœuds incluaient des machines multi-GPU parce que des clients les utilisaient pour du calcul, pas parce que c’était amusant.
Leur arme secrète n’était pas un ordonnanceur intelligent. C’était un changelog. Chaque nœud avait une version de pilote figée, une baseline firmware figée et une matrice simple « connue‑bonne ». Les mises à jour étaient staged : un nœud canari d’abord, puis un petit lot, puis le reste. Pas d’exceptions. Personne n’adorait ça. Ça paraissait lent.
Une semaine, un nouveau pilote a introduit des erreurs PCIe corrigeables intermittentes sur une révision de carte mère spécifique quand les deux GPU étaient sous charge mixte. Sur le poste d’un développeur, cela ressemblait à des crashes d’applis aléatoires. Dans la flotte, le nœud canari a commencé à émettre des logs AER en quelques heures.
Parce que le groupe avait une discipline ennuyeuse, ils ont corrélé la timeline, rollbacké le canari et bloqué le déploiement. Pas d’instabilité à l’échelle de la flotte, pas de reimagings massifs, pas de panique. Ils ont déposé un ticket fournisseur avec des logs reproductibles et une recette de reproduction précise.
Le « sauvetage » n’était pas un débogage héroïque. C’était la pratique opérationnelle des rollouts stagés et du verrouillage de versions. Les systèmes multi-GPU amplifient les problèmes marginaux ; la seule réponse sensée est de traiter les changements comme des changements de production, pas comme des expériences du week-end.
Listes de contrôle / plan étape par étape
Étape par étape : décider si le multi-GPU vaut la peine
- Définissez l’objectif. Est-ce un FPS moyen plus élevé, de meilleurs 1% low, ou une charge compute/render spécifique ?
- Identifiez le type de charge. Jeu temps réel avec effets temporels ? Supposez « non ». Rendu hors-ligne/compute ? Peut-être « oui ».
- Vérifiez la réalité du support. Si l’appli n’implémente pas le multi-GPU explicite et que le vendeur ne supporte plus les profils pilotes, arrêtez ici.
- Mesurez la base. Un seul GPU, pilote stable, temps de trame, utilisation VRAM, CPU par cœur.
- Ajoutez le second GPU. Vérifiez la largeur de lien PCIe, l’alimentation, la thermique et la topologie.
- Re-mesurez. Cherchez des améliorations sur le percentile 99 du temps de trame et sur le débit, pas seulement sur la moyenne FPS.
- Décidez. Si les gains sont faibles ou que le pacing est pire, retirez-le. La taxe de complexité est réelle.
Étape par étape : stabiliser une machine multi-GPU (si vous devez la faire tourner)
- Tournez d’abord avec les clocks stock. Des overclocks « stables » sur un GPU peuvent échouer en conditions thermiques dual-GPU.
- Validez le budget d’alimentation. Assurez-vous de la marge PSU ; évitez les câbles d’alimentation PCIe en chaîne pour forts draws.
- Verrouillez les versions. Bloquez pilote/firmware ; staged updates comme en production.
- Instrumentez. Loggez dmesg, événements AER, raisons de throttling GPU, températures et utilisations.
- Fixez les attentes. Pour le jeu, vous optimisez la stabilité et le pacing, pas des captures de benchmark.
FAQ
1) Est-ce que SLI/CrossFire a jamais vraiment fonctionné ?
Oui — parfois. Dans des titres bien profilés DX11 avec des pipelines amicaux à l’AFR et peu de dépendances temporelles, le scaling pouvait être important. Le problème est que « parfois » n’est pas une stratégie produit.
2) Pourquoi la VRAM ne s’additionnait-elle pas entre GPU pour les jeux ?
Parce que chaque GPU avait besoin d’un accès local aux textures et géométries à pleine vitesse, et le multi-GPU grand public répliquait typiquement les ressources par carte. Sans modèle de mémoire unifié, vous ne pouvez pas traiter deux pools de VRAM comme un seul sans payer de lourds coûts de synchronisation et de transfert.
3) Qu’est-ce que le micro-saccades, opérationnellement parlant ?
C’est la variance de latence. Vous livrez des trames à des intervalles incohérents — rafales et creux — donc le mouvement paraît irrégulier. C’est pourquoi le « FPS moyen » est une métrique dangereusement incomplète.
4) Pourquoi DX12/Vulkan ont rendu le multi-GPU plus rare au lieu de plus courant ?
Ils l’ont rendu explicite. C’est honnête architecturalement mais cela déplace le travail vers l’équipe moteur : gestion des ressources, synchronisation, tests sur combinaisons de GPU et couverture QA. La plupart des studios n’ont pas voulu financer cela pour une petite base d’utilisateurs.
5) Deux GPU différents peuvent-ils travailler ensemble pour le jeu aujourd’hui ?
Pas comme avant où le pilote le faisait pour vous. Le multi-adapter explicite peut, en théorie, utiliser des GPU hétérogènes, mais le support dans la réalité est rare et généralement spécialisé. Pour les jeux typiques : supposez non.
6) Et NVLink — ça règle le problème ?
NVLink aide dans certains scénarios pair-à-pair de bande passante et est précieux en calcul. Il ne résout pas automatiquement le pacing, les dépendances temporelles ni le problème économique logiciel. Les interconnexions ne corrigent pas l’architecture.
7) Si je possède déjà deux GPU, que devrais-je faire ?
Pour le jeu : utilisez un seul GPU et vendez l’autre, ou réutilisez-le pour du calcul/encodage. Pour le calcul : utilisez des frameworks qui supportent explicitement le multi-GPU et mesurez le scaling avec des tailles de batch réalistes et le surcoût de synchronisation.
8) Quelles métriques dois-je croire en testant le multi-GPU ?
Percentiles des temps de trame (comme le 99e), ressenti de latence d’entrée (difficile à mesurer, facile à remarquer), utilisation par GPU, marge VRAM et logs de stabilité. Le FPS moyen est une métrique de vanité dans ce contexte.
9) Le multi-GPU est-il complètement mort ?
Pas totalement — juste en tant que voie d’accélération par défaut pour le jeu temps réel grand public. Le multi-GPU prospère là où la charge peut être partitionnée proprement : rendu hors-ligne, calcul scientifique, ML et certaines pipelines de visualisation professionnelle.
Étapes suivantes que vous pouvez réellement entreprendre
Si vous pensez au multi-GPU pour le jeu en 2026, voici un conseil franc : n’en faites pas. Achetez le meilleur GPU unique que vous pouvez justifier, puis optimisez les temps de trame, la marge VRAM et une pile pilote stable. Vous obtiendrez un système comportementalement prévisible, ce que vous voulez quand c’est vous qui devez le déboguer.
Si vous devez absolument faire tourner du multi-GPU — parce que votre charge est du compute, du rendu hors-ligne ou de la visualisation spécialisée — traitez-le comme une infrastructure de production : verrouillez les versions, effectuez des rollouts stagés, instrumentez tout et supposez que le second GPU augmente votre surface de défaillance plus que votre performance.
Étapes pratiques suivantes :
- Basculez votre état d’esprit de test de « FPS moyen » vers les percentiles des temps de trame et des runs reproductibles.
- Validez la largeur de lien PCIe, la topologie et la stabilité d’alimentation avant de toucher aux pilotes.
- Décidez à l’avance si votre application utilise le multi-GPU explicite ; si non, arrêtez d’investir du temps.
- Conservez un pilote connu‑bon et traitez les mises à jour comme des rollouts contrôlés.