Resizable BAR / SAM : le petit interrupteur qui peut booster beaucoup

janvier 16, 2026 • février 3, 2026 • Lecture : 27 min • Views: 0

Cet article vous a aidé ?

Vous déployez une nouvelle carte graphique dans une flotte de stations de travail, lancez des benchmarks, et… rien. Ou pire : quelques machines gagnent en réactivité, quelques-unes subissent d’étranges saccades,
et une refuse de démarrer sauf le mardi. Le ticket s’intitule « régression des performances graphiques », mais la cause racine est un réglage BIOS que la plupart des gens
traitent comme un simple ornement.

Resizable BAR (et le nom marketing d’AMD, Smart Access Memory / SAM) est exactement ce type d’interrupteur : petit, facile à mal configurer, et capable
de déplacer de vraies charges de travail. C’est aussi un excellent moyen de découvrir combien de couches séparent « l’application demande une texture » et « les octets arrivent au GPU ».

Ce que Resizable BAR/SAM change réellement

Les périphériques PCI Express exposent des régions mappées en mémoire appelées BAR : Base Address Registers. C’est ainsi que le CPU (et le système d’exploitation) mappe les registres d’un périphérique et
parfois des portions de la mémoire du périphérique dans l’espace d’adressage système. Historiquement, les GPU n’exposaient qu’une petite « fenêtre » de leur VRAM au CPU à
un instant donné—communément 256 Mo—donc le CPU ne pouvait directement mapper et accéder qu’à une portion de la VRAM. Si le CPU devait accéder à une autre partie de la VRAM,
la fenêtre devait être remappée.

Resizable BAR est une capacité PCIe qui permet au firmware/au système d’exploitation de négocier une taille de BAR plus grande pour le périphérique—pouvant mapper beaucoup plus de
la VRAM du GPU dans l’espace d’adressage du CPU en une seule fois. Cela peut réduire le coût des remappages et améliorer le débit pour les charges de travail qui impliquent des
uploads pilotés par le CPU, le streaming d’actifs et de nombreux petits transferts. Parfois cela ne change rien. Parfois cela compte.

Smart Access Memory (SAM) d’AMD n’est pas une technologie différente ; c’est le packaging d’AMD combinant Resizable BAR + validation plateforme + une case BIOS qui
donne l’impression d’avoir débloqué quelque chose. Chez NVIDIA, c’est toujours Resizable BAR, généralement activé via le BIOS plus des profils pilote/jeu.

Voici le modèle mental pratique : Resizable BAR n’accélère pas le GPU en soi. Il change l’efficacité avec laquelle le CPU peut adresser et alimenter la mémoire GPU.
Si votre goulot d’étranglement est le débit des shaders, les cœurs de ray tracing, ou le GPU qui saturent déjà sa propre bande passante mémoire, la taille de la BAR ne vous sauvera pas.
Si votre goulot est « le CPU effectue beaucoup de petites interactions VRAM pendant le streaming », la taille de la BAR peut faire la différence.

L’explication hors-marketing : taille de fenêtre et remappages

Sans Resizable BAR, le CPU voit une petite fenêtre de la VRAM. Imaginez un entrepôt avec une trappe : vous pouvez passer des cartons, mais un à la fois et vous changez sans cesse l’étagère vers laquelle la trappe pointe.
Resizable BAR agrandit l’ouverture, parfois suffisamment pour voir tout l’entrepôt. Le surcoût de manipulation diminue. Si cela se traduit par des FPS en plus dépend de si le « coût de manipulation » était réellement votre facteur limitant.

Une citation, parce que les ops ont besoin d’une colonne vertébrale

L’espoir n’est pas une stratégie. — Ed Catmull (attribué dans les milieux d’ingénierie)

Faits et contexte : pourquoi cela existe

On n’obtient pas une case BIOS comme celle-ci sans une longue série de compromis. Voici des faits concrets et des jalons historiques utiles à connaître
avant de commencer à basculer des réglages en production.

Les BAR existent avant les GPU modernes. Les BAR font partie de la spécification PCI à une époque où « mémoire périphérique » signifiait souvent fenêtres de registres et petits buffers, pas 24 Go de VRAM.
256 Mo est devenu une aperture GPU de facto. Pendant des années, de nombreuses plateformes mappaient une BAR préfetchable de 256 Mo pour les GPU, ce qui était « acceptable » quand les tailles de VRAM et les schémas de trafic CPU↔GPU étaient différents.
Resizable BAR est une capacité PCIe, pas une invention d’un fournisseur. Le mécanisme existe dans PCIe, mais l’activation large côté consommateur a traîné car le firmware, l’OS et les piles de pilotes devaient tous se comporter correctement.
« Above 4G Decoding » concerne l’espace d’adressage, pas les performances. Cela permet au firmware d’allouer de l’espace MMIO PCIe au-dessus de la frontière 4 Go, essentiel quand de grandes BAR entrent en collision avec des fenêtres MMIO 32 bits limitées.
UEFI importe car la chaîne de démarrage alloue les ressources. Les chemins de démarrage Legacy/CSM et les anciennes attentes d’option ROM rendent souvent les allocations MMIO larges difficiles ou impossibles.
Les cartes serveur s’en sont souciées plus tôt que les cartes gaming. Les plateformes haut de gamme qui mappent de grandes régions MMIO (HBA, NICs avec SR-IOV, accélérateurs) ont poussé l’écosystème vers des comportements d’allocation plus sensés.
Les pilotes contrôlent le comportement de façon agressive. NVIDIA a historiquement activé Resizable BAR par jeu/profil car « ça marche sur le papier » n’est pas la même chose que « ça marche sur 500 moteurs avec 500 bizarreries ».
La virtualisation complique les choses. Le passthrough, les groupes IOMMU et l’allocation firmware à l’intérieur des VMs peuvent empêcher le mapping de grandes BAR même si l’hôte les supporte.
Ce n’est pas réservé au jeu. Certains pipelines de création de contenu et de calcul bénéficient quand les opérations côté CPU et la gestion mémoire côté GPU interagissent fortement.

Quand cela aide (et quand ce n’est pas le cas)

Où Resizable BAR a tendance à aider

Charges de travail lourdes en streaming d’actifs : jeux en monde ouvert, grandes scènes, streaming fréquent de textures/géométries.
Soumission de rendu limitée par le CPU avec beaucoup de transferts : le CPU passe du temps à coordonner les uploads et les transitions de ressources.
Certaines applications de création : projets volumineux, textures haute résolution, échanges fréquents de cache—selon l’architecture de l’application.
Benchmarks qui imitent le streaming réel : pas seulement « charge maximale des shaders », mais « charger/évincer/charger à nouveau ».

Où cela n’aide généralement pas

Scénarios purement limités par le GPU (haute résolution + shading intensif) où le GPU est déjà le facteur limitant.
Charges dominées par la bande passante mémoire locale du GPU plutôt que par les transactions CPU↔GPU.
Moteurs ou applications très anciens qui ne sollicitent pas le comportement de mapping VRAM côté CPU.
Systèmes limités par la topologie des lignes PCIe (x8 vs x16, uplinks de chipset) ou par l’E/S stockage qui alimente les actifs.

Vérification réaliste : c’est un bouton, pas un miracle

Resizable BAR peut produire des gains significatifs dans certains titres et workflows, mais ce n’est pas un bouton magique « performance gratuite ». La raison pour laquelle cela a fait un cycle de hype est simple : c’est l’un des rares changements au niveau plateforme qui peut montrer des gains mesurables sans acheter un nouveau GPU. Cela ne le rend pas universellement bénéfique ; cela le rend tentant.

Blague #1 : Resizable BAR, c’est comme donner une paille plus large à votre GPU—génial si vous étiez limité par la paille, inutile si vous étiez limité par la boisson.

Prérequis stricts et pièges de compatibilité

En environnements de production—oui, même les « stations de jeu en production » dans des labs d’entreprise—vous voulez un comportement déterministe. Resizable BAR a des prérequis.
Si l’un d’eux n’est pas rempli, vous obtiendrez une activation partielle, aucune activation, ou une activation avec effets secondaires bizarres.

Exigences plateforme (les suspects habituels)

Boot UEFI (CSM off dans la plupart des cas).
Above 4G Decoding activé dans le BIOS/UEFI.
Resizable BAR activé dans le BIOS/UEFI.
Support VBIOS GPU pour Resizable BAR.
Firmware de la carte mère qui alloue l’espace MMIO correctement (c’est là que « dernier BIOS » n’est plus optionnel).
Support OS + pilote (Windows et noyaux Linux modernes le supportent généralement, mais les pilotes peuvent toujours restreindre l’usage).

Pièges à surveiller activement

Environnements GPU mixtes : iGPU activé + dGPU + autres périphériques PCIe peuvent pousser l’allocation MMIO dans des cas limites.
Beaucoup de périphériques PCIe : NICs, HBAs, cartes NVMe add-in, cartes de capture—l’espace MMIO devient restreint.
Virtualisation/passthrough : l’invité peut ne pas pouvoir mapper de grandes BAR, ou l’hyperviseur peut les restreindre.
Anciennes option ROM : les attentes legacy des ROM peuvent entrer en conflit avec de grands mappings BAR.
UI « activé » suspecte : certains firmwares affichent la bascule mais n’allouent pas réellement une BAR plus grande.

Playbook de diagnostic rapide (première/deuxième/troisième)

Si vous déboguez une plainte de performance et que quelqu’un mentionne Resizable BAR, vous devez répondre rapidement à trois questions :
(1) est-ce réellement activé, (2) la charge y est-elle sensible, et (3) est-ce qu’autre chose est le goulot.

Première étape : vérifier que c’est activé de bout en bout

Vérifiez les réglages BIOS : Above 4G Decoding, Resizable BAR, CSM/Legacy boot.
Dans l’OS, confirmez que la taille de la BAR GPU est plus grande que la fenêtre legacy (souvent > 256M).
Confirmez que le pilote le reconnaît (NVIDIA Control Panel sous Windows ; sysfs/lspci sous Linux).

Deuxième étape : confirmez que vous mesurez le bon goulot

Utilisation GPU, utilisation VRAM, utilisation CPU par cœur.
Consistance des temps de trame (saccades vs FPS moyen).
Largeur/vitesse du lien PCIe (x16 Gen4 vs x8 Gen3 peut dominer les résultats).

Troisième étape : cherchez des conflits d’allocation de ressources

dmesg / journaux Windows pour avertissements d’allocation de ressources PCI.
Quirks IOMMU/ACS si le passthrough est impliqué.
Autres périphériques consommant de l’espace MMIO (plusieurs NVMe AICs, NICs SR-IOV).

Si vous ne pouvez pas prouver que c’est activé, arrêtez de discuter des benchmarks. Si vous pouvez prouver que c’est activé mais que rien ne change, supposez que vous n’êtes pas limité par la BAR.
Passez à autre chose.

Tâches pratiques avec commandes, sorties et décisions

Voici les tâches que j’exécute réellement quand quelqu’un dit « Resizable BAR est activé » ou « SAM a cassé ma machine ». Chaque tâche inclut une commande réaliste,
une sortie d’exemple, ce que la sortie signifie, et la décision qu’elle entraîne. Les commandes sont centrées Linux parce que Linux expose la vérité sans drame d’interface.
Vous pouvez adapter la logique aux outils Windows si nécessaire.

Task 1: Identify the GPU PCI address

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)

Signification : Le GPU est à 01:00.0. Vous utiliserez cette adresse pour toute inspection PCIe plus approfondie.
Décision : Verrouillez-vous sur le bon périphérique ; ne devinez pas quand plusieurs GPU existent.

Task 2: Check BAR sizes and whether they look “large”

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "Region 0|Region 2|prefetchable"
Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Region 2: Memory at 4000000000 (64-bit, prefetchable) [size=16G]

Signification : Une BAR préfetchable de 16G est un fort indicateur que Resizable BAR est actif et mappe une large aperture VRAM.
Le comportement legacy est souvent ~256M. Vos numéros de région peuvent varier.
Décision : Si vous voyez encore seulement une petite région préfetchable, retournez aux prérequis firmware/mode de démarrage.

Task 3: Confirm the Resizable BAR capability exists

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -n "Resizable BAR" -A6
214:	Capabilities: [bb0] Resizable BAR
215:		Resizable BAR: BAR 2: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB

Signification : Le périphérique annonce la capacité Resizable BAR et a négocié un mapping de 16GB.
Décision : Si la capacité est absente, vous aurez probablement besoin d’une mise à jour VBIOS GPU ou le GPU ne la supporte tout simplement pas.

Task 4: Check boot mode (UEFI vs legacy) quickly

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

Signification : Vous êtes démarré en UEFI.
Décision : Si vous obtenez « Legacy », désactivez CSM/Legacy boot et réinstallez ou convertissez le démarrage, sinon l’activation d’une grande BAR échoue souvent.

Task 5: Confirm kernel saw “Above 4G” style resource allocation without errors

cr0x@server:~$ dmesg -T | grep -iE "pci.*resource|BAR|mmio" | tail -n 8
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: BAR 2: assigned [mem 0x4000000000-0x43ffffffff 64bit pref]
[Mon Jan 20 09:41:05 2026] pci 0000:00:01.0: PCI bridge to [bus 01]
[Mon Jan 20 09:41:05 2026] pci_bus 0000:01: resource 0 [mem 0x4000000000-0x43ffffffff 64bit pref]

Signification : Le noyau a affecté avec succès une grande fenêtre préfetchable 64 bits.
Décision : Si vous voyez « not enough MMIO resources » ou des échecs d’affectation de BAR, attendez-vous à de l’instabilité ou à un fallback de la BAR.

Task 6: Validate PCIe link width and speed (the silent killer)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
LnkCap:	Port #0, Speed 16GT/s, Width x16, ASPM L0s L1
LnkSta:	Speed 16GT/s (ok), Width x16 (ok)

Signification : Vous fonctionnez à l’équivalent Gen4 x16 (16GT/s) et en pleine largeur. Bien.
Décision : Si cela montre x8 ou Gen3, réparez le placement, le choix du slot, la bifurcation BIOS, les risers, ou le routage du chipset avant de blâmer la BAR.

Task 7: Check IOMMU state (relevant for passthrough and some platforms)

cr0x@server:~$ dmesg -T | grep -iE "IOMMU|DMAR|AMD-Vi" | head
[Mon Jan 20 09:41:03 2026] AMD-Vi: IOMMU performance counters supported
[Mon Jan 20 09:41:03 2026] AMD-Vi: IOMMU enabled

Signification : IOMMU est activé. Bien pour l’isolation, parfois mauvais pour les chemins sensibles à la latence si mal configuré.
Décision : Si vous faites du passthrough GPU et que la grande BAR ne tient pas, il peut être nécessaire d’ajuster les paramètres hyperviseur qui autorisent de grands MMIO.

Task 8: Inspect sysfs resource mapping for the GPU

cr0x@server:~$ sudo cat /sys/bus/pci/devices/0000:01:00.0/resource
0x00000000f6000000 0x00000000f6ffffff 0x0000000000040200
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000004000000000 0x00000043ffffffff 0x000000000004220c

Signification : La troisième ligne montre une grande région mappée (0x4000… à 0x43ff…), cohérente avec une grosse BAR.
Décision : Si la région préfetchable est petite, ou manquante, votre activation n’est pas réelle.

Task 9: Confirm the driver loaded and which GPU is active

cr0x@server:~$ lsmod | grep -E "^nvidia|^amdgpu" | head
nvidia_drm             86016  3
nvidia_modeset       1241088  7 nvidia_drm
nvidia              62738432  340 nvidia_modeset

Signification : Les modules noyau NVIDIA sont chargés.
Décision : Si vous êtes sur le mauvais pilote (nouveau vs nvidia, ou un stack amdgpu incompatible), le comportement et les performances de la BAR seront imprévisibles.

Task 10: Check VRAM size and basic runtime stats (sanity)

cr0x@server:~$ nvidia-smi --query-gpu=name,pci.bus_id,memory.total,pcie.link.gen.current,pcie.link.width.current --format=csv
name, pci.bus_id, memory.total [MiB], pcie.link.gen.current, pcie.link.width.current
NVIDIA GeForce RTX 3090, 00000000:01:00.0, 24576 MiB, 4, 16

Signification : Confirme que vous interrogez le bon GPU et que le lien PCIe est sain.
Décision : Si le gen/width du lien est bas en charge, vérifiez la gestion d’énergie ou les réglages BIOS « PCIe speed ».

Task 11: Measure CPU vs GPU bound behavior during a run (quick and dirty)

cr0x@server:~$ sudo apt-get -y install sysstat >/dev/null
cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 	01/21/2026 	_x86_64_	(32 CPU)

09:52:10 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:52:11 AM  all   32.1  0.0  6.2   0.4    0.0  0.7    0.0    0.0    0.0   60.6
09:52:11 AM   7    97.0  0.0  2.0   0.0    0.0  0.0    0.0    0.0    0.0    1.0

Signification : Un cœur est saturé. Cela sent le goulot de soumission CPU ou une portion mono-thread du workload.
Décision : Si un ou deux cœurs sont saturés alors que l’utilisation GPU est faible, Resizable BAR peut aider un peu—mais vous devriez aussi chasser les causes côté CPU.

Task 12: Verify storage isn’t the actual “streaming” bottleneck

cr0x@server:~$ iostat -xm 1 3
Linux 6.5.0 (server) 	01/21/2026 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.10    0.00    5.92    6.33    0.00   59.65

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await  aqu-sz  %util
nvme0n1         820.0  94200.0     0.0    0.00    7.10   114.88    12.0    980.0   2.10    5.90   94.0

Signification : Le dispositif NVMe est à ~94% d’utilisation avec un await non négligeable. Le streaming d’actifs peut être saturé par le stockage.
Décision : Si le stockage est saturé, les changements de BAR ne régleront pas le hitching ; corrigez l’I/O (stockage plus rapide, meilleur caching, moins de contention) d’abord.

Task 13: Check hugepages/THP and basic memory pressure (stutter can be memory)

cr0x@server:~$ grep -E "MemTotal|MemAvailable|SwapTotal|SwapFree" /proc/meminfo
MemTotal:       131840512 kB
MemAvailable:    18422528 kB
SwapTotal:      16777212 kB
SwapFree:        1024000 kB

Signification : Vous êtes bas en mémoire disponible et le swap est majoritairement utilisé. Cela peut provoquer de mauvaises variations de temps de trame sans relation avec la BAR.
Décision : Si une pression mémoire existe, corrigez cela avant d’attribuer des améliorations/régressions à la BAR.

Task 14: Enumerate other PCIe devices competing for MMIO space

cr0x@server:~$ lspci | grep -E "Ethernet|Non-Volatile memory|SATA|RAID|Fibre|Infiniband"
03:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
05:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02)

Signification : Plusieurs périphériques peuvent requérir des fenêtres MMIO ; avec une grande BAR, l’allocation peut devenir serrée.
Décision : Si l’activation de la BAR échoue sur des systèmes « pleinement chargés » mais fonctionne sur des systèmes minimaux, envisagez de réduire les périphériques, changer de slots, ou mettre à jour le firmware.

Task 15: Check if the kernel clamped BAR sizes (common with quirks)

cr0x@server:~$ dmesg -T | grep -iE "Resizable BAR|resizable|clamp|re-size|rebar" | tail -n 20
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: enabling Extended Tags
[Mon Jan 20 09:41:05 2026] pci 0000:01:00.0: BAR 2: resized to 16GB

Signification : Le noyau a explicitement redimensionné la BAR.
Décision : Si vous voyez des lignes « failed to resize », vous n’obtenez pas la fonctionnalité même si le BIOS dit « Enabled ».

Task 16: (Virtualization) Check QEMU/KVM for large BAR readiness on the host

cr0x@server:~$ sudo dmesg -T | grep -i vfio | tail -n 8
[Mon Jan 20 10:03:12 2026] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[Mon Jan 20 10:03:12 2026] vfio-pci 0000:01:00.0: BAR 2: can't reserve [mem 0x4000000000-0x43ffffffff 64bit pref]

Signification : VFIO ne peut pas réserver cette grande fenêtre BAR pour le passthrough tel que configuré actuellement.
Décision : Vous devez ajuster les réglages hyperviseur/firmware VM (par ex. autoriser de grands MMIO, OVMF, espace d’adressage invité) ou accepter l’absence de grande BAR dans l’invité.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une équipe média a déployé de nouvelles stations pour des monteurs. Même modèle de GPU que le pilote. Même paquet de pilotes. Même image OS. La seule différence était la
révision de la carte mère—subtilement changée par les achats parce que « équivalente ».

Les machines du pilote montraient de belles améliorations lors du scrubbing des timelines et de la cohérence d’aperçu après l’activation de Resizable BAR. Le playbook de déploiement disait :
« Activer ReBAR + Above 4G, valider avec un benchmark, expédier. » Ce playbook supposait que « Activé dans le BIOS » signifiait « Activé en réalité ».

En une semaine, les tickets d’assistance ont afflué : écrans noirs intermittents, plantages d’applications pendant l’export, et quelques machines qui gelaient complètement sous charge. Le benchmark utilisé pour la validation ne déclenchait pas le problème ; la charge réelle d’édition, si.

La cause racine n’était pas mystique. Sur les cartes « équivalentes », le firmware allouait les ressources PCIe différemment quand plusieurs disques NVMe et une carte 10GbE étaient installés. Avec la grande BAR activée, la plateforme touchait un cas limite de ressources. Les logs OS montraient des tentatives de réaffectation de BAR et des échecs occasionnels.
Certains démarrages retombaient silencieusement ; d’autres laissaient le pilote GPU dans un état instable.

La correction fut ennuyeuse : mise à jour du firmware, guide de population de slots plus strict, et une étape de vérification explicite côté OS (taille de BAR dans lspci) comme condition. L’hypothèse erronée était de penser qu’une bascule UI constitue un contrat. C’est une suggestion.

Mini-récit 2 : L’optimisation qui a tourné au fiasco

Une petite équipe ML faisait de l’inférence accélérée GPU sur une ferme de stations partagées—parce qu’acheter des serveurs dédiés était « le trimestre prochain », ce qui veut dire « pas pour tout de suite ». Ils ont remarqué que certaines charges avaient une variance de latence plus faible sur une machine et ont demandé ce qui était différent.

Quelqu’un a découvert que Resizable BAR était activé sur cette machine et a décidé de l’activer partout. Pas de contrôle de changement. Pas de déploiement progressif. Juste une amélioration « performance » un vendredi après-midi.

Lundi matin, un sous-ensemble de nœuds a commencé à lancer des resets GPU sous forte concurrence. Pas tous. Seulement ceux avec un modèle particulier de carte de capture installé pour un projet séparé. Les resets ressemblaient à de l’instabilité pilote, donc la première réaction fut de réinstaller les pilotes. Cela n’a pas aidé.

Finalement, le motif est apparu : les systèmes avec la carte de capture avaient une disposition MMIO plus serrée, et l’activation d’une grande BAR a poussé la plateforme dans une configuration techniquement légale mais pratiquement fragile. Sous charge, les chemins de récupération d’erreur étaient chaotiques. Désactiver ReBAR a tout stabilisé.

L’échec n’était pas que Resizable BAR soit « mauvais ». C’était que l’équipe a optimisé une dimension (débit possible) et ignoré les contraintes et l’hétérogénéité de la plateforme. Une bascule appliquée à toute la flotte sans conscience topologique n’est pas une optimisation, c’est de l’improvisation.

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

Un groupe produit gérait un labo mixte Windows et Linux pour les tests de moteur de jeu. Ils avaient une politique : toute bascule de performance au niveau BIOS requiert un enregistrement avant/après sur une charge représentative, plus un artefact lisible par machine stocké avec le rapport de test.

Ça avait l’air bureaucratique jusqu’à ce que ça ne le soit plus. Une nouvelle version de BIOS est arrivée et un lot de machines a été mis à jour. La pipeline nocturne de performance du labo a signalé une petite régression de la consistance des temps de trame sur un sous-ensemble de systèmes. Le FPS moyen était correct. Le « ressenti » ne l’était pas.

Parce que le labo stockait des artefacts de vérification, il fut trivial de voir ce qui avait changé : la taille de la BAR était retombée à une petite fenêtre après la mise à jour BIOS,
même si l’UI du BIOS affichait toujours Resizable BAR activé. La mise à jour UEFI avait aussi modifié le comportement CSM sur certains profils.

La correction fut rapide : imposer le boot UEFI uniquement, réappliquer les bons réglages firmware, et bloquer cette build BIOS jusqu’à validation. Pas de supputations, pas de « peut-être c’est le pilote ». Juste des preuves, puis une action.

La pratique ennuyeuse—traiter les bascules firmware comme des risques de dérive de configuration—a sauvé des jours de débats et a maintenu la crédibilité du labo.

Erreurs courantes : symptômes → cause → correctif

1) « Le BIOS indique activé, mais les performances n’ont pas changé »

Symptômes : Aucun gain ; les outils OS affichent toujours une BAR ~256Mo ; benchmarks inchangés.
Cause racine : Boot CSM/Legacy, Above 4G Decoding manquant, ou firmware qui n’alloue pas de grand MMIO donc la BAR n’a jamais été négociée.
Fix : Démarrer en UEFI, désactiver CSM, activer Above 4G Decoding + ReBAR, mettre à jour le BIOS, puis confirmer avec lspci -vv la taille de la BAR.

2) « J’ai activé ReBAR et maintenant écrans noirs / resets pilote aléatoires »

Symptômes : Chutes d’affichage intermittentes, logs de resets GPU, instabilité sous charge.
Cause racine : Cas limite d’allocation MMIO/ressources avec d’autres périphériques PCIe ; parfois aggravé par risers/bifurcation.
Fix : Mettre à jour le BIOS, simplifier la topologie PCIe, déplacer les cartes vers d’autres slots, tester avec un minimum de périphériques ; si l’instabilité persiste, désactiver ReBAR.

3) « Ça marche jusqu’à ce qu’on ajoute une autre carte NVMe »

Symptômes : ReBAR cesse de se négocier ou le système échoue au POST après ajout de périphériques PCIe.
Cause racine : Épuisement de l’espace MMIO ou politique d’allocation firmware médiocre.
Fix : Assurer Above 4G Decoding, mettre à jour le firmware, réduire les cartes add-in, ou choisir des cartes mères avec une meilleure gestion des ressources PCIe.

4) « Le stutter a empiré même si le FPS moyen s’est amélioré »

Symptômes : FPS moyen en hausse, mais pics de hitching augmentés.
Cause racine : Vous avez déplacé le goulot : maintenant le stockage I/O, la pression mémoire, la compilation de shaders, ou l’ordonnancement CPU domine les temps de trame.
Fix : Mesurez l’utilisation du stockage (iostat), la pression RAM (/proc/meminfo), la saturation CPU par cœur (mpstat) et corrigez ces points.

5) « La VM en passthrough ne voit pas ReBAR »

Symptômes : L’hôte montre une grande BAR, l’invité montre une petite BAR ou échoue à démarrer la VM avec des erreurs de ressources.
Cause racine : Firmware invité/config VM n’autorise pas de grands MMIO ; VFIO ne peut pas réserver la grande BAR ; contraintes IOMMU.
Fix : Utiliser UEFI (OVMF) pour l’invité, configurer de grandes fenêtres MMIO, assurer que l’hôte peut réserver les ressources ; sinon accepter que cela ne fonctionnera pas dans cette topologie.

6) « Nous l’avons activé sur toute la flotte et certaines machines ont perdu l’affichage au boot »

Symptômes : Pas de sortie vidéo au démarrage, ou blocage sur le splash vendor.
Cause racine : Problèmes de compatibilité firmware/option ROM, surtout avec des GPU anciens ou des réglages legacy mixtes.
Fix : Revenir via un reset BIOS, mettre à jour le VBIOS GPU, imposer UEFI-only, et dérouler le déploiement en canaris.

Blague #2 : Si votre plan de changement est « basculer l’interrupteur BIOS et profiter », félicitations—vous venez d’inventer le Chaos Engineering pour ceux qui détestent les tableaux de bord.

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

Plan de changement pour une station de travail unique (sûr et rapide)

Capturer la baseline. Enregistrez la version du pilote, la version du BIOS, et un benchmark ou trace de workload représentatif (moyenne + 1% lows/temps de trame).
Mettre à jour le firmware d’abord. Si vous n’êtes pas sur un BIOS raisonnablement récent, n’essayez pas. Trop de bugs d’allocation vivent là.
Passer en UEFI-only. Désactivez CSM/Legacy boot. Vérifiez que Linux montre /sys/firmware/efi.
Activer Above 4G Decoding. C’est le réglage « faire de la place ».
Activer Resizable BAR. Sauvegardez, redémarrez.
Vérifier dans l’OS. Utilisez lspci -vv et confirmez une grande BAR préfetchable et la taille négociée dans la capacité Resizable BAR.
Relancer le même workload. Comparez le débit moyen et la latence en queue/consistance des temps de trame.
Décider : garder ou revenir. Gardez si cela améliore la métrique que vous ciblez sans ajouter d’instabilité. Revenez en arrière si cela ajoute de la fragilité ou n’aide pas.

Plan de déploiement canary pour une flotte (ce que font réellement les SRE)

Segmenter la flotte par topologie matérielle. Même révision de carte mère importe. Même VBIOS GPU importe. Même population de cartes add-in importe.
Choisir des canaris par segment. Pas une seule machine héroïque. Au moins quelques-unes par topologie.
Définir des métriques de succès. Pas « on a l’impression que c’est plus rapide ». Choisissez mesurables : frame time p95, temps de compilation, durée d’export, taux de crash.
Automatiser la vérification. Collectez des snippets lspci -vv ou des lignes sysfs resource comme artefacts.
Déployer avec plan de rollback. Documentez comment revenir aux réglages BIOS à distance ou via procédure manuelle.
Surveiller les échecs corrélés. Surtout avec des périphériques PCIe additionnels et après des mises à jour firmware.

Règle décisionnelle simplifiée

Activer si vous pouvez vérifier une grande BAR dans l’OS et que votre workload est sensible au streaming / transferts CPU.
Ne pas déranger si vous êtes limité par le GPU et stable ; vous poursuivez probablement du bruit.
Désactiver si vous voyez de l’instabilité ou si l’activation casse une topologie PCIe auparavant fonctionnelle.

FAQ

1) SAM est-il différent de Resizable BAR ?

Pas fondamentalement. SAM est l’implémentation brandée d’AMD de Resizable BAR avec validation plateforme et valeurs par défaut. Le mécanisme sous-jacent est PCIe Resizable BAR.

2) Ai-je besoin d’Above 4G Decoding ?

Dans la plupart des systèmes réels, oui. Les grands mappings BAR consomment de l’espace MMIO, et Above 4G Decoding permet au firmware d’allouer cet espace au-dessus de 4 Go où il y a de la place.

3) Pourquoi mon BIOS affiche « activé » mais Linux montre toujours une petite BAR ?

Causes communes : vous démarrez en legacy/CSM, le firmware a échoué à allouer à cause d’autres périphériques, ou la combinaison GPU VBIOS/firmware n’a pas négocié la fonctionnalité.
Faites confiance à lspci -vv plutôt qu’à la case à cocher.

4) Resizable BAR peut-il réduire les saccades ?

Oui, dans les charges où les transferts CPU↔GPU et le surcoût de remappage contribuent aux pics de temps de trame. Mais le stutter est souvent dû au stockage, à la pression mémoire,
à la compilation de shaders, ou à l’ordonnancement CPU. Mesurez avant d’attribuer l’amélioration à la BAR.

5) Cela aide-t-il les workloads de calcul/ML ?

Parfois, surtout si le workflow met fréquemment en scène des données du CPU vers la mémoire GPU selon des schémas qui bénéficient de mappings plus larges.
Beaucoup de pipelines ML sont dominés par le calcul GPU et la bande passante mémoire GPU, où la taille de la BAR change peu.

6) Est-il sûr d’activer cela sur une flotte de postes de travail ?

C’est sûr si vous le traitez comme tout changement firmware : déroulez-le progressivement, vérifiez la négociation au niveau OS, et surveillez les taux de crash/écrans noirs. C’est dangereux si vous le basculez sur
du matériel hétérogène en le traitant comme « identique ».

7) Pourquoi certains fournisseurs l’activent-ils seulement pour certains jeux ?

Parce que l’écosystème est chaotique. Certains moteurs et chemins pilotes bénéficient ; d’autres peuvent régresser ; certains peuvent déclencher des cas limites. Le gating par profil est une tactique pragmatique de contrôle du risque.

8) Puis-je l’utiliser avec du passthrough GPU vers une VM ?

Ça dépend. L’hôte peut le supporter, mais l’invité a besoin d’assez d’espace MMIO et d’un firmware UEFI qui peut mapper la grande BAR. Beaucoup de setups passthrough requièrent une configuration explicite de « large MMIO ».

9) Quelle est la meilleure preuve qu’il fonctionne sous Linux ?

Une grande taille de BAR préfetchable dans lspci -vv (souvent plusieurs Go) plus la capacité « Resizable BAR » montrant une taille courante non triviale.

10) Si cela n’aide pas, dois-je le désactiver ?

Si vous ne voyez aucun bénéfice et que vous valorisez la prévisibilité maximale, oui—désactivez-le et simplifiez. Si c’est stable et que vous gérez un environnement à charges mixtes,
le laisser activé est raisonnable tant que vous pouvez vérifier qu’il reste activé après des mises à jour firmware.

Conclusion : étapes pratiques suivantes

Resizable BAR/SAM est l’un de ces rares interrupteurs plateforme qui peut légitimement améliorer des workloads réels—quand le workload est sensible et que la plateforme
alloue les ressources proprement. C’est aussi un excellent moyen de mettre en lumière des firmware fragiles, des topologies PCIe surchargées, et des habitudes de benchmarking qui ignorent la latence de queue.

Vérifier, ne pas supposer. Confirmez la taille de la BAR dans l’OS. Si elle n’est pas grande là, elle n’est pas activée.
Mesurer la bonne chose. Utilisez les temps de trame ou les latences p95/p99, pas seulement le débit moyen.
Corriger les goulots évidents d’abord. La largeur/vitesse du lien PCIe, la saturation du stockage, et la pression mémoire dominent souvent les « débats sur la BAR ».
Déployer comme un adulte. Faire des canaris par topologie matérielle, suivre la dérive firmware, et garder un plan de rollback.

Si vous voulez une politique en une phrase : activez Resizable BAR où vous pouvez prouver qu’elle est négociée et qu’elle améliore la métrique que vos utilisateurs perçoivent réellement ; sinon,
laissez-la désactivée et profitez d’une file d’incidents plus calme.