Pilotes Arc : comment une génération de GPU se corrige en public

novembre 26, 2025 • février 3, 2026 • Lecture : 30 min • Views: 0

Cet article vous a aidé ?

Le problème : vous avez acheté une nouvelle génération de GPU et elle se comporte comme un produit en bêta. Les jeux saccadent. Les encodeurs perdent des images. Vos graphiques de monitoring mentent parce que le pilote indique « 99% GPU » alors que le thread CPU est en réalité en surcharge.

Intel Arc est un cas d’étude particulièrement visible parce qu’il est arrivé sur un marché qui s’attend à « installer le pilote, profiter ». Au lieu de ça, Arc a forcé tout le monde — Intel inclus — à réapprendre une leçon ancienne : un GPU n’est pas qu’un circuit, c’est une plateforme logicielle qui contient un circuit.

Ce que signifie vraiment « corrigé en public »

Quand on dit « les pilotes Arc sont en train d’être réparés », on imagine souvent une équipe monolithique qui bascule quelques interrupteurs. La réalité est plus désordonnée et plus intéressante.

Un « pilote » GPU moderne est une pile :

Pilote en mode noyau : ordonnancement, gestion mémoire, alimentation, commutation de contexte. Sur Linux pour Arc, il s’agit du pilote i915 (pour Alchemist) et des composants adjacents.
Pilote en mode utilisateur : implémentation des API (Direct3D, Vulkan, OpenGL), compilateur de shaders, caches de pipeline, couches de traduction.
Firmware : le code du contrôleur interne du GPU. Oui, on peut livrer un « nouveau silicium » puis corriger le comportement par firmware, dans certaines limites.
Couches runtime : DXVK, vkd3d-proton, caches de shaders propres aux jeux, injecteurs d’overlay, hooks anti-triche.
Contraintes de plateforme : réglages du BIOS comme Resizable BAR, bizarreries de carte mère, comportement du scheduler Windows, topologie PCIe.

« Corrigé en public » signifie que les utilisateurs voient l’évolution en temps réel : nouveaux pilotes toutes les quelques semaines, listes de problèmes connus, régressions, solutions de contournement, et parfois le fait dérangeant que la meilleure correction est « attendre la prochaine release ». Dans le logiciel d’entreprise, on fait comme si ça n’arrivait pas. Pour les GPU, tout le monde regarde ça se produire.

Arc a rendu cela visible parce que c’était la première vraie offensive de Intel sur les GPU discrets depuis longtemps, et ça arrivait avec l’attente moderne que DX11, DX12, Vulkan, OpenGL, encodage/décodage vidéo, streaming, capture, overlays et jeux étranges de 2009 fonctionnent tous correctement dès le premier jour. Cette attente est irréaliste, mais c’est aussi le contrat imposé par le marché.

Pourquoi Arc a été livré imparfait (et pourquoi ce n’était pas surprenant)

Si vous gérez des systèmes en production, vous connaissez le schéma : une nouvelle plateforme est livrée avec la « fonctionnalité de base » correcte, mais c’est dans les cas limites et la compatibilité héritée que votre alarme sonne. Les GPU sont un sanctuaire des cas limites.

Les problèmes de réputation initiaux d’Arc n’étaient pas seulement des « bugs ». Ils étaient structurels :

1) DX11 n’est pas « ancien », c’est une autre philosophie

Les jeux de l’ère DX11 supposent souvent que les pilotes feront beaucoup de travail : validation d’état, décisions de compilation de shaders, aide au regroupement d’appels de dessin, et l’habitude « j’appelle l’API 40 000 fois par frame ». Ce n’est pas juste inefficace ; c’est une dépendance à un comportement historiquement lourd côté pilote.

L’architecture et la pile logicielle d’Arc se sont orientées vers des API explicites modernes (DX12/Vulkan) où les moteurs font plus d’orchestration. Lorsque vous traduisez des charges DX11 sur ces paradigmes modernes, vous pouvez payer un surcoût exactement au mauvais endroit : le thread CPU qui alimente le GPU.

2) Resizable BAR n’était pas optionnel en pratique

Arc a tiré un avantage inhabituel de Resizable BAR (ReBAR). Sans lui, vous pouvez subir davantage de churn de mapping PCIe et des schémas d’accès mémoire moins efficaces entre CPU et GPU. Beaucoup des premiers rapports « Arc est lent » étaient en réalité « Arc sans ReBAR est lent », ce qui est un diagnostic très différent.

3) La compilation de shaders et le cache de pipeline sont là où vit la « saccade »

La saccade est rarement un problème unique. C’est souvent une séquence : un nouveau variant de shader apparaît, le pilote le compile (parfois plusieurs fois), le cache de pipeline rate, la latence de stockage monte, et votre pacing d’images s’effondre. Le GPU peut être inactif alors que l’utilisateur perçoit un « lag GPU ».

4) La matrice de tests est absurde

Les jeux ne ressemblent pas à des bases de données où l’on teste un ensemble de requêtes connu. Ce sont des moteurs sur mesure avec des bugs sur mesure. Ajoutez overlays, outils de capture, utilitaires RGB et anti-triche, et vous êtes en train de fuzz-er votre pilote avec des logiciels consommateurs.

Idée paraphrasée, attribuée à John Allspaw : La fiabilité se construit en apprenant des échecs en conditions réelles, pas en supposant qu’on peut tester toutes les possibilités à l’avance.

Une vérité opérationnelle : les fournisseurs de GPU ne peuvent pas « terminer » un pilote en laboratoire. Ils ne peuvent que les rendre assez bons, puis apprendre en production — aka votre poste.

La pile des pilotes : qui fait quoi et où se cachent les bugs

Si vous voulez déboguer Arc comme un SRE (plutôt que comme un fil de forum), vous avez besoin d’une carte mentale de la pile et des modes de défaillance typiques.

Stack Windows (simplifié)

Pilote noyau WDDM : ordonnancement, paging mémoire, timeouts (TDR), comportement de préemption.
Pilote mode utilisateur : implémentation D3D11/D3D12/Vulkan ; compilateur de shaders ; gestion de l’état de pipeline.
Runtime DirectX et moteur de jeu : peut masquer du travail dans des appels au pilote ; peut déclencher des variants pathologiques de shaders.

Où se cachent les bugs : surcharge de traduction DX11, timeouts TDR pendant la compilation de shaders, états d’alimentation incorrects, ou régression issue d’« on a corrigé un jeu » qui en casse un autre.

Stack Linux (simplifié)

Noyau : i915 (pour Arc Alchemist) : gestion mémoire GEM/TTM, chargement des firmwares GuC/HuC, ordonnancement.
Mesa en espace utilisateur : ANV (Vulkan), iris (OpenGL), backends du compilateur.
Couches de traduction : DXVK (DX9/10/11 sur Vulkan), vkd3d-proton (DX12 sur Vulkan).
Compositeur : Wayland/Xorg ; VRR ; le pacing peut aussi devenir étrange ici.

Où se cachent les bugs : incompatibilités noyau/firmware, écarts de version Mesa, firmware manquant, latence du compositeur, et jeux qui supposent un comportement spécifique au fournisseur.

L’histoire « corrigé en public » d’Arc ressemble souvent à ceci :

Les utilisateurs signalent : « Le jeu X a des 1% lows catastrophiques. »
Le fournisseur triage : est-ce un goulet CPU, un cache de shaders, une surcharge DX11, ou un TDR ?
Une correction arrive dans une couche (changement du cache de shaders en mode utilisateur).
Une régression apparaît (un autre jeu tombe sur un nouveau chemin, ou l’invalidation du cache a modifié le comportement).
La correction est affinée, parfois à travers plusieurs couches (pilote + firmware + profil jeu).

Faits et contexte historique à ressortir au dîner

Fait 1 : Intel a livré des GPU discrets bien avant Arc — pensez à l’i740 à la fin des années 1990 — mais Arc est la première poussée grand public depuis des décennies avec des attentes modernes de jeu.
Fait 2 : Resizable BAR est une extension du comportement d’adressage PCIe ; c’est une « idée ancienne, devenue pratique » grâce à la standardisation récente des plateformes grand public.
Fait 3 : Les pilotes DX11 faisaient historiquement beaucoup de travail « utile » parce que les jeux en dépendaient ; les API explicites (DX12/Vulkan) ont déplacé cette responsabilité vers les moteurs, changeant où apparaissent les bugs de performance.
Fait 4 : La saccade due à la compilation de shaders existe depuis l’existence des shaders ; ce qui a changé, c’est la complexité des shaders et l’explosion des permutations causées par les fonctionnalités modernes de rendu.
Fait 5 : Le firmware GPU est mis à jour davantage comme le firmware d’une carte réseau que comme une microcode CPU : fréquemment, ciblé, et souvent couplé au comportement du pilote.
Fait 6 : DXVK et vkd3d-proton ont rendu les jeux Windows sur Linux viables à grande échelle, et ils sont aussi devenus des outils diagnostiques accidentels pour la qualité des pilotes en offrant des chemins alternatifs.
Fait 7 : La consistance du temps d’image (1% lows) importe souvent plus pour la sensation de fluidité que la moyenne FPS ; les pilotes peuvent améliorer la « sensation » sans changer significativement les benchmarks principaux.
Fait 8 : Beaucoup de problèmes de « performance » GPU sont en réalité des problèmes d’ordonnancement CPU ou de synchronisation : spinlocks, contention sur mutex, et soumission de rendu mono-thread.

Blague n°1 : Une release de pilote GPU est le seul endroit où « stabilité corrigée » peut signifier « on a arrêté d’être stable à 12 FPS. »

Méthode de diagnostic rapide

Voici la méthode « j’ai 30 minutes avant de retourner la carte / revenir au pilote précédent / blâmer le jeu ». L’objectif est d’identifier rapidement la catégorie du goulot, pas d’atteindre l’illumination.

Première étape : classer la défaillance

Crash : plantage de l’application, reset du pilote, écran noir, TDR, gel du GPU.
Saccade : pics de temps d’image, accrocs sur les rotations de caméra, pauses périodiques.
Basse performance : FPS constamment bas, faible utilisation GPU, CPU saturé.
Corruption visuelle : artefacts, scintillements, textures manquantes, éclairage incorrect.
Problèmes d’encodage/décodage : images perdues, désynchronisation, forte utilisation CPU lors de l’encodage.

Deuxième étape : déterminer si c’est plateforme, pilote ou charge

Vérifications plateforme : ReBAR activé, BIOS à jour, vitesse du slot PCIe correcte, connecteurs d’alimentation, thermiques.
Sanité du pilote : bonne version, réinstallation propre si nécessaire, pas de conflit d’overlay, pas de runtime ancien traînant.
Chemin de la charge : DX11 vs DX12 vs Vulkan ; essayer des API de rendu alternatives ; tester DXVK sur Windows comme test de contrôle si vous savez ce que vous faites.

Troisième étape : collecter deux timelines

Timeline des temps d’image : voir si la saccade corrèle avec une compilation de shader ou du streaming.
Timeline système : CPU, IO disque, utilisation VRAM, fréquences GPU, débit PCIe.

Quatrième étape : prendre une décision rapide

Si ReBAR est désactivé : activez-le, retestez. Si vous ne pouvez pas : vous êtes en mode « gestion des attentes ».
Si seuls les titres DX11 sont mauvais : privilégiez DX12/Vulkan si possible ; sinon testez des versions de pilote connues pour améliorer les chemins DX11.
Si la saccade se produit dans de nouvelles zones/scènes : cache de shaders/cache de pipeline ; options de précompilation ; réduire les réglages qui augmentent les permutations (RT, ombres).
Si les crashes coïncident avec des pics de fréquence : gestion d’alimentation ; essayer une limite de puissance conservatrice ou désactiver les boosts agressifs.

Tâches pratiques : commandes, sorties, décisions

Ce sont des vraies tâches « faites ça maintenant ». Chaque élément inclut : commande, sortie exemple, ce que ça signifie, et la décision à prendre. Mixez selon Windows vs Linux. Ne lancez pas de scripts aléatoires depuis Internet ; exécutez des commandes ciblées qui répondent à une question.

Task 1 (Linux): Confirm the GPU and driver binding

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,/Kernel modules/p'
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:56a0] (rev 05)
	Subsystem: Device [8086:1020]
	Kernel driver in use: i915
	Kernel modules: i915

Signe : Le noyau utilise i915 pour le GPU Intel. Si vous voyez « vfio-pci » ou aucun pilote, vous ne testez pas le vrai chemin.

Décision : Si ce n’est pas i915, corrigez le binding (ou arrêtez : votre problème n’est pas « les pilotes Arc », c’est l’affectation du périphérique).

Task 2 (Linux): Check whether GuC/HuC firmware actually loaded

cr0x@server:~$ dmesg | grep -E "i915|GuC|HuC" | tail -n 12
[    2.143210] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/dmc_ver2_20.bin
[    2.198341] i915 0000:00:02.0: [drm] GuC firmware i915/guc_70.5.1.bin version 70.5.1
[    2.198379] i915 0000:00:02.0: [drm] HuC firmware i915/huc_7.10.3.bin version 7.10.3
[    2.207511] i915 0000:00:02.0: [drm] GuC submission enabled

Signe : Le firmware s’est chargé et la soumission GuC est activée. Un firmware manquant peut se traduire par un ordonnancement dégradé, un comportement d’alimentation erratique, et une instabilité aléatoire.

Décision : Si le chargement du firmware échoue, installez le package linux-firmware approprié pour votre distribution et redémarrez ; ne continuez pas à benchmarker une base cassée.

Task 3 (Linux): Validate Vulkan driver and device exposure

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

Devices:
========
GPU0:
  apiVersion         = 1.3.275
  driverVersion      = 24.1.3
  vendorID           = 0x8086
  deviceID           = 0x56a0
  deviceName         = Intel(R) Arc(TM) A770 Graphics
  driverID           = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
  deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU

Signe : Mesa ANV est en usage, Arc est vu comme GPU discret, et Vulkan fonctionne.

Décision : Si le device apparaît comme llvmpipe ou rasterizer logiciel, arrêtez et corrigez la pile graphique. Si Vulkan fonctionne mais que les jeux DX11 saccadent, suspectez la traduction ou le cache de shaders.

Task 4 (Linux): Confirm OpenGL driver path (iris vs something wrong)

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Intel(R) Arc(TM) A770 Graphics (DG2) (0x56a0)
    Version: 24.1.3
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Arc(TM) A770 Graphics (DG2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.3

Signe : L’accélération matérielle est active, Mesa est le renderer.

Décision : Si « direct rendering: No » ou renderer est « llvmpipe », vous dépannez la mauvaise chose. Corrigez d’abord votre setup Mesa/DRM.

Task 5 (Linux): Watch GPU frequency and power behavior under load

cr0x@server:~$ sudo intel_gpu_top -s 2000
intel-gpu-top: Intel DG2 (Gen12.7) @ /dev/dri/card0

      Render/3D    Blitter     Video     VideoEnhance     EU Array     Frequency
         78.22%      0.00%      2.13%          0.00%        76.90%       2050 MHz

Signe : Vous saturiez réellement le render ; les clocks boostent. Si le render est bas mais le FPS est bas, vous êtes CPU-bound ou bloqué sur une synchronisation/surcharge du pilote.

Décision : Render bas + FPS bas → investiguer le thread CPU, surcharge DX11, ou le pacing d’images ; Render haut + FPS bas → vous êtes GPU-bound, réduisez les réglages ou vérifiez thermiques/alimentation.

Task 6 (Linux): Check for GPU hangs/resets in the journal

cr0x@server:~$ sudo journalctl -k -b | grep -E "i915|GPU HANG|reset" | tail -n 20
Jan 21 10:14:22 server kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dffffb, in game.exe [4123]
Jan 21 10:14:23 server kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Jan 21 10:14:24 server kernel: i915 0000:00:02.0: [drm] game.exe[4123] context reset due to GPU hang

Signe : Vrai GPU hang/reset, pas « le jeu a crashé ». Cela peut venir du pilote, du firmware, ou d’une alimentation/overclock instable.

Décision : Reproduisez à clocks stock, mettez à jour kernel/Mesa/firmware, et si c’est un seul titre, essayez un autre chemin API. Si les hangs persistent sur plusieurs charges, traitez-le comme un problème de stabilité plateforme.

Task 7 (Windows, via PowerShell): Confirm driver version and date

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_VideoController | Select-Object Name,DriverVersion,DriverDate"
Name                                  DriverVersion       DriverDate
----                                  -------------       ----------
Intel(R) Arc(TM) A770 Graphics        31.0.101.5592       20250110

Signe : Vous avez une build de pilote précise ; c’est votre baseline pour les tests de régression.

Décision : Si vous avez un pilote très ancien, mettez à jour avant de déboguer. Si vous êtes sur le plus récent et qu’il y a une régression, testez une version antérieure connue stable pour confirmer la régression.

Task 8 (Windows): Detect TDR events (driver resets) in Event Viewer logs

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ID=4101} -MaxEvents 5 | Format-Table TimeCreated,Message -AutoSize"
TimeCreated           Message
-----------           -------
1/21/2026 10:02:11    Display driver igdkmdn64 stopped responding and has successfully recovered.
1/20/2026 22:41:58    Display driver igdkmdn64 stopped responding and has successfully recovered.

Signe : Windows a reseté le pilote d’affichage. Ce n’est pas « juste un crash », c’est un timeout ou un hang.

Décision : Réduisez les vecteurs d’instabilité (overclocks, undervolts), puis changez une variable à la fois : version du pilote, API du jeu, ou limite de puissance. Si les TDR corrèlent avec des écrans de compilation de shaders, suspectez un chemin pilote qui bloque trop longtemps.

Task 9 (Windows): Verify Resizable BAR status

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDeviceProperty -InstanceId (Get-PnpDevice -Class Display | Where-Object {$_.FriendlyName -like '*Arc*'}).InstanceId -KeyName 'DEVPKEY_Device_BusReportedDeviceDesc' | Select-Object Data"
Data
----
PCI Express Root Complex

Signe : Ceci ne confirme pas directement ReBAR ; Windows ne fournit pas toujours une commande simple. En pratique vous validez ReBAR dans le BIOS ou avec des outils constructeur ; sur Linux vous pouvez inspecter les tailles de BAR directement.

Décision : Si vous ne pouvez pas affirmer avec confiance que ReBAR est activé, arrêtez de benchmarker et allez vérifier le BIOS : Above 4G Decoding + ReBAR activés, CSM désactivé dans bien des cas.

Task 10 (Linux): Confirm BAR sizing and whether ReBAR is active

cr0x@server:~$ sudo lspci -vv -s 00:02.0 | grep -E "Region 0|Resizable BAR|BAR 0" -A2
Region 0: Memory at 6000000000 (64-bit, prefetchable) [size=16G]
Capabilities: [200 v1] Resizable BAR
		Resizable BAR: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB

Signe : BAR 0 est mappée à 16G, ce qui est typiquement ce qu’on souhaite pour les caractéristiques de performance d’Arc.

Décision : Si la taille courante est minuscule (256MB/512MB) alors que le supporte est plus grand, activez ReBAR/Above 4G Decoding dans le BIOS et retestez. Si votre plateforme ne le permet pas, acceptez que vous ne voyez pas le comportement prévu de la carte.

Task 11 (Linux): Identify whether you’re CPU-bound in a game via perf sampling

cr0x@server:~$ sudo perf top -p $(pidof game.exe) -n 5
Samples: 1K of event 'cpu-clock', Event count (approx.): 250000000
Overhead  Shared Object        Symbol
  18.42%  game.exe             RenderThread::SubmitDraws
  12.10%  libvulkan_intel.so   anv_queue_submit
   9.77%  game.exe             ShaderManager::GetVariant
   6.31%  libc.so.6            pthread_mutex_lock

Signe : Le thread de rendu CPU et la soumission de queue sont chauds ; il y a de la contention sur mutex. C’est le classique « surcharge pilote/API rencontre design du moteur ».

Décision : Essayez une autre API (DX12/Vulkan), réduisez les réglages gourmands en draw calls (distance d’affichage, densité de foule), et assurez-vous que la version du pilote inclut des améliorations DX11 connues si c’est le cas.

Task 12 (Linux): Observe shader cache growth and whether it’s being invalidated

cr0x@server:~$ du -sh ~/.cache/mesa_shader_cache ~/.cache/radv_builtin_shaders 2>/dev/null
1.2G	/home/cr0x/.cache/mesa_shader_cache

Signe : Le cache de shaders existe et est volumineux ; c’est normal pour les titres modernes.

Décision : Si la saccade persiste après plusieurs runs dans la même scène, le cache peut être désactivé, constamment invalidé, ou la saccade vient du streaming/CPU. Si le dossier de cache ne grossit jamais, investiguez les variables d’environnement ou le sandboxing empêchant l’écriture.

Task 13 (Linux): Check storage latency when stutter happens

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.02    0.00    5.21    6.11    0.00   70.66

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
nvme0n1         520.0  42000.0     0.0   0.00   8.40    80.77     70.0   9000.0   4.10   2.90   88.20

Signe : Forte utilisation NVMe et latence de lecture élevée pouvant corréler avec la saccade, surtout lors du streaming de nouvelles zones.

Décision : Si %util monte à 100% pendant les saccades, déplacez le jeu vers un stockage plus rapide, assurez-vous de ne pas paginer, et envisagez des options de précompilation. Ne chassez pas un « problème pilote GPU » quand votre disque est en souffrance.

Task 14 (Windows): Validate GPU scheduling mode and HAGS state (where supported)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers' /v HwSchMode"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Signe : Le scheduling GPU accéléré matériellement est activé (la valeur peut varier selon la version de Windows).

Décision : Si vous diagnosez des saccades ou de la latence, testez HAGS en activant/désactivant. Certains systèmes s’améliorent ; d’autres régressent. Traitez-le comme un flag de fonctionnalité, pas comme une religion.

Task 15 (Linux): Confirm you’re not accidentally on a software compositor path

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Signe : Vous êtes sur Wayland. C’est acceptable, mais si un jeu spécifique saccade, tester Xorg peut isoler une interaction avec le compositeur.

Décision : Si les problèmes disparaissent sur Xorg, vous avez trouvé un bug du compositeur/chemin VRR, pas un problème brut de performance GPU.

Task 16 (Linux): Capture a minimal GPU debug report without guessing

cr0x@server:~$ sudo intel_gpu_top -J -s 500 -o /tmp/intel_gpu_top.json & sleep 5; head -n 5 /tmp/intel_gpu_top.json
{
  "period_us": 500000,
  "device": "Intel DG2",
  "timestamp": 39421.1201,

Signe : Vous avez un enregistrement structuré de l’utilisation des moteurs GPU pour corréler avec les moments de saccade.

Décision : Si l’utilisation est basse pendant le « lag », arrêtez de blâmer le cœur GPU. Regardez la soumission CPU, la compilation de shaders, ou l’IO.

Trois mini-histoires d’entreprise depuis le terrain

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

L’entreprise déployait des stations de travail basées sur Arc pour une équipe faisant un mix d’encodage vidéo et de 3D légère. Rien d’exotique. Le groupe pilote semblait content : encode AV1 rapide, bureaux silencieux, prix correct. Les achats souriaient. Cela aurait dû être un signal d’alerte.

La deuxième semaine, une vague de tickets arrive : « L’UI se fige 2–3 secondes », « l’écran devient noir puis revient », « les appels se coupent lors du partage d’écran ». L’équipe a traité ça comme un problème d’application de conférence. Ils ont réinstallé l’app, l’ont mise à jour, essayé une autre webcam. Ping-pong classique des responsabilités.

La mauvaise hypothèse était subtile : ils supposaient que le GPU se comporterait comme « juste un iGPU plus rapide ». Dans leur environnement, les réglages BIOS étaient standardisés depuis des années — CSM activé pour compatibilité de boot legacy, ReBAR désactivé parce que « ça n’a jamais compté », et les mises à jour BIOS étaient perçues comme risquées.

Une fois que quelqu’un a finalement vérifié la baseline plateforme, c’était évident : la moitié du parc avait ReBAR désactivé et le firmware obsolète. Sous la charge d’un encodage temps réel plus le compositing et les overlays de partage d’écran, le pilote atteignait des bords de timing et récupérait (TDR sur Windows), ce que les utilisateurs percevaient comme des gels.

La correction n’était pas magique : mise à jour BIOS, activation d’Above 4G Decoding + ReBAR, standardisation de la version pilote, et cesser de mélanger « ce que Windows Update a fourni » avec des installations manuelles. Les performances se sont améliorées et les écrans noirs ont disparu. La vraie leçon : Arc est sensible à la configuration plateforme d’une manière que des GPU plus anciens pouvaient masquer par un comportement différent.

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

Une autre organisation gérait une petite ferme de rendu pour des aperçus d’actifs. Ils ne faisaient pas de rendu hors-ligne complet ; ils exécutaient des rendus de viewport interactifs et encodaient des clips de revue. Quelqu’un a remarqué des répertoires de cache de shaders devenant des gigaoctets sur les profils utilisateurs et a décidé que c’était « des écritures SSD gaspillées ».

Ils ont donc poussé une politique : vider les caches de shaders à la déconnexion, et rediriger les caches vers un répertoire home réseau pour garder les profils « stateless ». Sur le papier, c’était une hygiène IT propre. Le lundi, tout le monde s’est plaint que les 10 premières minutes de chaque session étaient pleines de saccades, les ventilateurs hurlaient, et parfois des applis plantaient pendant le « chargement ».

Ce qui s’est passé : les caches de shaders et de pipeline étaient désormais froids à chaque connexion et, pire, stockés sur un chemin réseau à latence plus élevée et à contention occasionnelle. La compilation qui était amortie sur des semaines était maintenant écrasée dans les premières minutes de la journée, exactement quand les utilisateurs lançaient les applis et chargeaient les projets.

Arc a été blâmé parce que c’était la nouvelle variable, mais la véritable régression était auto-infligée. Restaurer les caches locaux, les exclure des « nettoyages », et les laisser persister a résolu les saccades. Ils ont quand même géré la croissance disque en mettant des quotas réalistes et en nettoyant seulement les caches vraiment orphelins, pas les plus chauds.

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

Un labo de test de jeux (pas un studio ; pensez compatibilité et QA externalisée) devait valider une mise à jour de pilote sur des dizaines de titres. Ils avaient l’habitude du churn fournisseur, donc ils ont fait ça comme un déploiement opérationnel, pas comme un hobby du week-end.

Ils maintenaient une image gold par classe matérielle : version BIOS figée, statut ReBAR figé, build Windows figée, version pilote figée. Chaque changement faisait l’objet d’une demande de changement avec une courte justification. C’était terriblement ennuyeux. C’était aussi la manière d’éviter de chasser des fantômes.

Quand un nouveau pilote Arc a amélioré les performances DX11 sur plusieurs titres mais introduit un crash dans un vieux moteur, le labo l’a détecté en quelques heures. Parce que leur baseline était stable, ils ont pu reproduire de façon fiable. Ils avaient aussi une « machine témoin » qui restait sur le pilote précédent pour confirmer qu’il s’agissait d’une régression, pas d’un hasard.

Résultat : ils ont fourni des étapes de repro actionnables, des logs cohérents et des comparaisons claires. Le fournisseur a corrigé le crash dans une release suivante. Le labo n’a pas « eu de la chance ». Ils ont fait le travail peu glamour : figer les baselines, mesurer les deltas, et refuser de mélanger des changements non liés dans la même fenêtre de test.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement spécifique. Si vous reconnaissez un symptôme, vous devriez pouvoir faire quelque chose de concret en moins d’une heure.

1) Faible FPS uniquement en DX11

Symptôme : les titres DX12/Vulkan tournent bien ; les titres DX11 montrent une faible utilisation GPU et de mauvais 1% lows.
Cause racine : soumission de draw CPU-limitée et surcharge pilote DX11 ; parfois les chemins de traduction sont moins optimisés que la concurrence.
Correction : privilégier DX12/Vulkan si disponible. Sinon, tester des pilotes plus récents connus pour améliorer DX11. Réduire les réglages gourmands en draw calls (distance d’affichage, foules). Assurer que ReBAR est activé.

2) Saccade qui ne disparaît jamais, même après plusieurs runs

Symptôme : même scène saccade à chaque fois ; le cache de shaders ne semble pas aider.
Cause racine : cache de shaders qui ne persiste pas (permissions, sandboxing, scripts de nettoyage), ou cache de pipeline invalidé par des mises à jour du pilote/changements de config.
Correction : vérifier que les répertoires de cache sont écrits et persistants. Arrêter les outils de « cleanup » qui suppriment les caches. Après une mise à jour de pilote, attendre une recompilation unique ; si ça se répète, vous avez un problème de persistance de cache.

3) Écrans noirs aléatoires avec récupération

Symptôme : écran devient noir une seconde puis revient ; Event ID 4101 sur Windows, ou reset GPU dans les logs Linux.
Cause racine : TDR / récupération après hang GPU déclenchée par une compilation de shader longue, boost/power instable, ou un bug pilote activé par une charge spécifique.
Correction : revenir à des clocks stock. Essayer une autre version de pilote. Réduire les pics de puissance (limiter FPS, abaisser légèrement la limite de puissance). Si c’est reproductible sur un seul titre, changer le chemin API et rapporter avec les logs.

4) « GPU à 99% » mais sensation de lenteur

Symptôme : les overlays montrent une utilisation GPU maximale, mais le pacing est catastrophique.
Cause racine : métriques d’utilisation trompeuses pendant les stalls, ou vous satuez un moteur spécifique (copy/video) tandis que le render est bloqué sur une sync.
Correction : utiliser des outils par moteur (intel_gpu_top) ou des graphes de frame-time. Corréler avec CPU et IO. Ne pas tuner sur la base d’un seul chiffre « GPU % ».

5) Les performances chutent après un « nettoyage » ou un outil de profil

Symptôme : après un optimise système, les jeux saccadent plus et se chargent plus lentement.
Cause racine : suppression du cache de shaders, services en arrière-plan désactivés dont les pilotes dépendent, changements de plan d’alimentation, ou paramètres forcés du pilote.
Correction : annuler le nettoyage. Restaurer les plans d’alimentation par défaut. Laisser les caches de shaders persister. Éviter les « tweakers » tiers sauf si vous pouvez inverser chaque changement.

6) L’encodage utilise trop le CPU malgré la présence d’Arc

Symptôme : OBS/FFmpeg saturent le CPU ; moteurs vidéo GPU montrent une faible utilisation.
Cause racine : encodeur incorrect sélectionné (x264 logiciel au lieu de QSV/oneVPL), chemin codec non supporté, ou mismatch pilote/runtime.
Correction : sélectionner explicitement l’encodeur matériel Intel. Valider avec les outils d’utilisation (activité du moteur vidéo). Mettre à jour pilote et runtimes médias en même temps.

7) Gaming Linux : « Vulkan fonctionne, mais Proton plante »

Symptôme : les applis Vulkan natives tournent ; certains titres Proton plantent/gelent.
Cause racine : interaction vkd3d-proton/DXVK avec une version spécifique du pilote/Mesa ; bibliothèques Vulkan 32-bit manquantes ; ou Mesa LTS obsolète sur la distro.
Correction : s’assurer que les pilotes Vulkan 32-bit sont installés. Mettre à jour Mesa (ou utiliser une stack connue-bonne). Garder kernel + Mesa + firmware alignés.

Blague n°2 : « C’est probablement le pilote » est l’équivalent GPU de « c’est DNS » — souvent correct, et toujours pas une excuse pour sauter les vérifications basiques.

Checklists / plan étape par étape

Checklist A : Établir une baseline fiable (faire une fois par machine)

Mettre à jour le BIOS vers une release vendor stable ; activer Above 4G Decoding et ReBAR.
Confirmer que le slot PCIe fonctionne à la largeur/vitesse attendue (ne pas benchmarker en ayant commis l’erreur d’un slot x4).
Installer une version de pilote connue-bonne ; l’enregistrer (capture d’écran ou log texte).
Désactiver les overlays/injecteurs inutiles pour les tests de baseline (outils de capture, overlays RGB, overlays de performance multiples).
Choisir 3 charges : un DX11, un DX12/Vulkan, un test encode/décode.
Enregistrer : FPS moyen, 1% lows, et si la saccade survient après la deuxième exécution (cache chaud).

Checklist B : Si vous suspectez une régression

Changer une seule variable : uniquement la version du pilote. Pas le build Windows, pas le BIOS, pas le patch du jeu, pas tout à la fois.
Re-tester la même scène/benchmark deux fois (cache froid puis cache chaud).
Vérifier les TDR/resets GPU (Event ID 4101 Windows / GPU HANG journal Linux).
Si la régression est confirmée, garder les deux installateurs de pilote et documenter : titre, mode API, résolution, réglages, étapes de reproduction.

Checklist C : Si vous poursuivez une saccade (pacing)

Déterminer si la saccade est ponctuelle (seulement au premier run) ou persistante.
Surveiller la latence stockage pendant les fenêtres de saccade ; éliminer la contention IO.
Valider la persistance du cache de shaders (ne pas le supprimer ; ne pas le déplacer sur stockage réseau).
Limiter FPS pour réduire les pics et les transitoires de puissance ; retester.
Changer le mode API (DX11 → DX12/Vulkan) comme test A/B.
Si persistant et reproductible, collecter les logs et remonter le bug avec la version de pilote exacte.

Checklist D : Alignement Linux « arrêtez de perdre du temps »

Kernel, Mesa et linux-firmware doivent être raisonnablement récents et compatibles.
Confirmer que ANV/iris sont utilisés (pas llvmpipe).
Confirmer que les firmwares GuC/HuC se chargent (dmesg).
Privilégier Wayland ou Xorg selon le comportement reproductible ; ne pas argumenter de manière abstraite.

FAQ

Q1: Pourquoi Arc s’est-il tant amélioré avec le temps comparé à d’autres lancements ?

Parce qu’Arc est arrivé avec beaucoup de « nouvelle surface de pile » en même temps : plateforme discrète nouvelle, fonctionnalités médias modernes, et fort focus sur les API explicites. Les améliorations les plus rapides sont venues en optimisant les chemins chauds (surtout la traduction/surcharge DX11), le comportement du cache de shaders, et les contournements spécifiques aux jeux. Ce sont des problèmes logiciels — et le logiciel peut évoluer plus vite que le silicium.

Q2: Resizable BAR est-il obligatoire ?

Pas strictement, mais fonctionnellement oui si vous tenez à des performances cohérentes. Arc tend à souffrir de manière disproportionnée quand la taille du BAR est petite. Si vous ne pouvez pas activer ReBAR, recalibrez vos attentes et benchmarquez avant de vous engager.

Q3: Pourquoi DX11 se comporte-t-il souvent pire que DX12/Vulkan sur Arc ?

DX11 encourage le pilote à faire plus de travail implicite. Cela peut créer une surcharge CPU et des coûts de synchronisation qui se traduisent par une faible utilisation GPU et de mauvais 1% lows. DX12/Vulkan transfèrent plus de responsabilité au moteur, ce qui peut mieux correspondre aux forces d’Arc quand le jeu est bien implémenté.

Q4: Quelle est la manière la plus rapide pour différencier un goulet CPU d’un goulet GPU ?

Baisser fortement la résolution et les paramètres graphiques. Si le FPS change à peine, vous êtes probablement CPU-bound ou limité par la surcharge pilote. Si le FPS augmente nettement, vous étiez GPU-bound. Confirmez avec l’utilisation par moteur (intel_gpu_top sur Linux) et les graphes de frame-time.

Q5: Dois-je toujours installer le pilote le plus récent ?

Pour Arc, « le plus récent » apporte souvent de vraies corrections, mais peut aussi introduire de nouvelles régressions. Si vous privilégiez la stabilité, choisissez une version connue-bonne et ne mettez à jour que lorsque vous avez besoin d’un correctif ou que les notes de version mentionnent clairement votre charge. Gardez l’installateur précédent pour pouvoir revenir en arrière facilement.

Q6: Les « optimisations spécifiques aux jeux » sont-elles des rustines sales ?

Ce sont une réalité. Parfois ce sont des heuristiques du compilateur de shaders ; parfois des flags de contournement pour un bug moteur ou un mauvais usage de l’API. L’alternative est de laisser les utilisateurs souffrir. Le risque opérationnel est la régression : un contournement peut changer le comportement ailleurs, d’où l’importance des tests de baseline.

Q7: Sur Linux, qu’est-ce qui compte le plus : le noyau ou Mesa ?

Les deux, mais pour la performance quotidienne et la compatibilité des jeux, Mesa fait souvent bouger l’aiguille le plus vite (driver Vulkan/OpenGL et compilateur). Pour la stabilité, l’ordonnancement et l’intégration du firmware, le noyau et linux-firmware sont tout aussi critiques. Traitez-les comme un ensemble.

Q8: Pourquoi j’ai des saccades après chaque mise à jour de pilote ?

Parce que les caches de shaders et de pipeline peuvent être invalidés quand le compilateur change. C’est attendu une fois. L’erreur est de supposer qu’une mise à jour de pilote est « gratuite ». Prévoir un run d’échauffement après la mise à jour, et ne pas évaluer la saccade dans les cinq premières minutes d’un cache froid.

Q9: La maturité du moteur média d’Arc suit-elle celle du pilote jeu ?

Pas parfaitement. Les pipelines médias (encodage/décodage) sont des chemins de code différents et peuvent être stables alors que des jeux ne le sont pas. Ils partagent toutefois des parties de la pile : gestion d’alimentation, mémoire et intégration OS. Si vous voyez des resets GPU pendant l’encodage, considérez-le comme un problème de stabilité système, pas « juste OBS ».

Q10: Que dois-je inclure quand je rapporte un bug pilote Arc pour que ce soit actionnable ?

Version pilote, build OS, version BIOS, statut ReBAR, version exacte du jeu, mode API précis (DX11/DX12/Vulkan), étapes de reproduction, et si ça arrive au second run (cache chaud). Ajoutez les logs (événements TDR / lignes GPU HANG du noyau) et une courte vidéo si c’est une corruption visuelle.

Conclusion : prochaines étapes qui réduisent vraiment la douleur

Si vous ne retenez qu’une chose : arrêtez de traiter « les pilotes Arc » comme une seule chose. C’est une pile, et chaque couche a ses modes de défaillance. La plupart du temps perdu provient du débogage sans avoir d’abord prouvé votre baseline : statut ReBAR, bon binding du pilote, firmware chargé, et un cas de test reproductible.

Faites ceci ensuite :

Verrouillez une baseline : BIOS + ReBAR + une version de pilote. Notez-la.
Classez votre douleur : crash vs saccade vs faible FPS vs bugs visuels. Outils et corrections différents selon le cas.
Exécutez la méthode de diagnostic rapide : plateforme → sanité du pilote → chemin de la charge. Ne sautez aucune étape.
Changez une variable à la fois : c’est ainsi que vous trouvez les régressions et évitez les superstitions.
Gardez les caches locaux et persistants : votre futur vous remerciera à chaque fois qu’une scène se chargera sans accroc.

L’histoire d’Arc est à quoi ressemble l’évolution GPU quand on peut l’observer : désordonnée, itérative, et parfois humiliante. La bonne nouvelle : les plateformes logicielles peuvent s’améliorer considérablement — si vous mesurez les bonnes choses et refusez de déboguer au feeling.