PCIe Resizable BAR en Moderne GPU's — Intel Arc, NVIDIA en AMD

Wat Een BAR Is, en Waarom GPU’s Eroverheen Groeiden

Elk PCIe-apparaat legt een of meer Base Address Registers bloot. Een BAR vertelt het systeem hoeveel adresruimte het apparaat wil, en de firmware mapt die in de geheugenkaart van de host. Zodra het gemapt is, bereikt de CPU het geheugen van het apparaat met gewone loads en stores.

De grootte van een BAR lag vroeger vast in silicium. De firmware las die uit bij het inschakelen en daarmee was het gesprek klaar.

Dat was prima toen BAR’s klein waren. Een netwerkkaart wil een paar tientallen kilobytes voor zijn registers. Een NVMe-controller wil 16KB tot 64KB.

Grafische kaarten braken de regeling. Een moderne kaart heeft 8, 12, 16 of 24GB videogeheugen, en het voor de hand liggende is om het allemaal te mappen zodat de CPU er overal in kan schrijven. Vaste BAR’s konden dat niet uitdrukken, dus werd de conventie een klein venster — meestal 256MB — dat de driver over de framebuffer herpositioneert en er stukje bij beetje doorheen kopieert. Het werkt. Het is alleen een idiote hoeveelheid boekhouding om geheugen te bereiken dat je al gekocht en ingebouwd hebt.

Wat Resizable BAR Verandert

Resizable BAR is een PCIe-capability waarmee de grootte van een BAR onderhandeld kan worden in plaats van vast te liggen. Het apparaat adverteert de groottes die het ondersteunt, en de firmware of het besturingssysteem programmeert er een.

Voor een GPU betekent dat dat de hele framebuffer in één keer gemapt kan worden. De driver stopt met pagineren door een venster en schrijft waar hij bedoelt te schrijven. De kernel rapporteert de capability als Physical Resizable BAR, en die is vendorneutraal. Een AMD-kaart werkt ermee op een Intel-platform en omgekeerd.

Wat De Drie Vendors Werkelijk Doen

Het interessante is dat de vendors het oneens zijn over hoeveel het uitmaakt.

Intel Arc en Arc Pro — Intel Noemt Het Vereist

Intel is de nadrukkelijke. Hun richtlijn zegt dat Resizable BAR “required to get a good experience with Intel® Arc™ hardware” is. Dat is ongewoon sterke taal voor een platformfeature, en het toont hoe de Arc-driver is gebouwd in plaats van een marketingkeuze.

Aan de symptoomkant beschrijft Intel het effect van het uitzetten ervan in termen van consistentie in plaats van gemiddelden: met “ReBAR off” zul je “generally result in spikes that were already there getting bigger.” Dat is een argument over frametime-stabiliteit, en het is dezelfde vorm van probleem als het effect van ASPM op latency-staarten. Het gemiddelde verbergt het.

Intel noemt Intel Core-processors van de 10e generatie en nieuwer, de meeste Ryzen 3000-serie en alle Ryzen 5000-CPU’s als ondersteunde platforms, en behandelt het als een moederbord-BIOS-feature die je moet gaan inschakelen.

De praktische conclusie voor Arc en Arc Pro is simpel. Als je een Arc-kaart in een machine hebt gezet en de prestaties zijn teleurstellend of ongelijkmatig, controleer dit dan voordat je iets anders controleert. Het is dan ook niet zozeer een afstelknop op die kaarten als wel een voorwaarde.

NVIDIA — Vanaf Ampere, en Alleen Waar Het Helpt

NVIDIA voegde in maart 2021 ondersteuning toe voor GeForce RTX 30 Series-kaarten en -laptops. Het werkend krijgen vereiste een ondersteunde VBIOS, een compatibele CPU en moederbord, een firmware-update van het moederbord, en een actuele driver. De RTX 3060 werd ermee geleverd; de 3060 Ti, 3070, 3080 en 3090 hadden mogelijk een firmware-update nodig om het te krijgen.

NVIDIA’s eigen prestatiekader is verfrissend ongeglamoureerd. Ze vonden dat “some titles benefit from a few percent, up to 12%” terwijl “there are also titles that see a decrease in performance.”

Hun antwoord daarop is het detail dat de moeite waard is te kennen: in plaats van het globaal aan te laten, test NVIDIA titels vooraf en gebruikt profielen per game om Resizable BAR alleen in te schakelen waar het als winst werd gemeten. Dus op een NVIDIA-kaart heeft “staat ReBAR aan?” een antwoord per applicatie, en een benchmark die niks toont kan simpelweg een titel zijn die de driver besloot met rust te laten.

AMD — Smart Access Memory Is Hetzelfde

AMD’s branding ervoor is Smart Access Memory, geïntroduceerd naast de Radeon RX 6000-serie en Ryzen 5000-CPU’s. De marketing suggereert een AMD-CPU-plus-AMD-GPU-koppeling, en zo werd het gelanceerd, maar de capability eronder is de standaard-PCIe-versie. Schakel Resizable BAR in in firmware met een Radeon-kaart in een Intel-machine en je krijgt dezelfde feature zonder de branding.

Radeon Pro W-serie-kaarten ondersteunen het ook. Op oudere architecturen — Vega en Polaris — is de ondersteuning lappiger, en dat is ook waar virtualisatieproblemen wonen.

Resizable BAR en AI-Werk

Dit is waar de feature verkeerd wordt begrepen, dus het is de moeite waard duidelijk te zijn over wat het raakt.

Resizable BAR verandert hoe de CPU het GPU-geheugen bereikt. Dat is het overdrachtspad — modelgewichten klaarzetten, batches doorsturen, resultaten teruglezen. Het raakt de eigen geheugenbandbreedte van de GPU niet, en het maakt een matrixvermenigvuldiging niet sneller.

De eerlijke samenvatting is dus dat het het laden en voeden van een model beïnvloedt, niet de rekenkunde. Voor een groot model is de host-naar-device-kopie bij het laden een echte kostenpost, en een BAR op volledige grootte laat de CPU rechtstreeks in het device-geheugen schrijven in plaats van te schuttelen door een patrijspoort van 256MB. Voor de steady state van een inference-run — waar de gewichten al resident zijn en het werk compute-bound is. Verwacht niks.

Drie specifieke punten zijn de moeite waard te kennen.

Arc Pro voor AI erft Intels oordeel. Als Intel zegt dat de kaart Resizable BAR nodig heeft voor een goede ervaring, geldt dat voor een kaart die oneAPI of PyTorch draait net zozeer als een die een game draait. Arc- en Arc Pro-kaarten die inference doen zouden het ingeschakeld moeten hebben, punt uit.

Op NVIDIA is het getal dat je wilt BAR1. BAR1 is het host-zichtbare venster op het device-geheugen, en het is waar host-gemapte allocaties en GPUDirect RDMA doorheen gaan:

# How much device memory is actually host-visible
nvidia-smi -q | grep -A3 "BAR1 Memory Usage"

Een datacenterkaart is met een grote BAR1 gebouwd. Op een desktopkaart is Resizable BAR wat dat venster groot maakt in plaats van klein. Als je RDMA rechtstreeks vanaf een NIC in GPU-geheugen doet, is dit geen fijnigheid.

Verwar dit niet met de eis van ROCm. AMD’s ROCm-systeemvereisten vragen om CPU’s die PCIe atomics ondersteunen — “modern CPUs after the release of 1st generation AMD Zen CPU and Intel™ Haswell” — en zeggen niets over BAR-grootte. Dat zijn twee verschillende platformvereisten die allebei in hetzelfde BIOS-menu leven, en mensen verwarren ze voortdurend. Controleer degene die je werkelijk nodig hebt.

De faalmodus die AI-builds het hardst bijt, is helemaal geen prestatie, en die staat hieronder: meerdere large-BAR-GPU’s in één machine kunnen de adresruimte laten opraken.

Wat Het Nodig Heeft Om Te Werken

Vier dingen, en ze zijn allemaal op firmwareniveau:

• Resizable BAR ingeschakeld in de moederbordfirmware. Vaak standaard uit.
• Above 4G Decoding ingeschakeld. Een BAR van 24GB past niet onder de 4GB-lijn, dus het platform moet bereid zijn adresruimte erboven toe te wijzen. Zet dit aan, zelfs zonder GPU aanwezig. Het kost niets.
• UEFI-boot, met CSM uit. Legacy-compatibiliteitsmodus en grote BAR’s gaan niet samen.
• Actuele firmware en drivers, in het bijzonder op de borden en kaarten uit de overgang van 2020–2021, waar ondersteuning per update kwam in plaats van bij de lancering.

Hoe Te Controleren Op Linux

Of de kaart de capability heeft, en welke groottes hij aanbiedt:

# Substitute your card's address from lspci
lspci -vvs 0000:XX:00.0 | grep -A6 "Physical Resizable BAR"

De kernel legt dit ook bloot in sysfs, één bestand per resizable BAR:

cat /sys/bus/pci/devices/0000:XX:00.0/resource1_resize

Die waarde is een bitmap van ondersteunde groottes, geen grootte. Bit 0 betekent 1MB, bit 1 betekent 2MB, bit 2 betekent 4MB, en de grootte voor een gegeven bit is 2 ^ (bit + 20). Dus 00000000000001c0 heeft bits 6, 7 en 8 gezet, wat betekent dat de BAR 64MB, 128MB of 256MB kan zijn.

Om te zien wat er werkelijk van kracht is, lees je de toegewezen regio’s:

lspci -vvs 0000:XX:00.0 | grep -i Region

Een kaart die met zijn volledige framebuffer gemapt draait, toont een regio die overeenkomt met zijn VRAM-grootte in plaats van een van 256MB.

Met De Hand Aanpassen

Je kunt de bitpositie zelf schrijven:

# bit 7 -> 2 ^ (7 + 20) = 128MB
echo 7 > /sys/bus/pci/devices/0000:XX:00.0/resource1_resize

De bijbehorende voorwaarden zijn streng, en de moeite waard te lezen voordat je het probeert op een machine waar je om geeft. Elke driver moet eerst van het apparaat worden losgekoppeld. Peer-apparaten onder dezelfde parent bridge moeten mogelijk zacht worden verwijderd. Op een VGA-apparaat breekt het schrijven van een resize-waarde de low-level console-drivers af. Alles wat de resourceN-sysfs-bestanden open houdt, moet loslaten.

De kerneldocumentatie is ook bot over het resultaat: succes is niet gegarandeerd. De resize faalt als er geen adresruimte is om de grotere BAR te plaatsen. Wat je meteen terugbrengt bij Above 4G Decoding.

Als Het Misgaat

dmesg zegt dat het de BAR niet kan toewijzen. Berichten in de vorm BAR 0: no space for [mem size ...] betekenen dat de allocatie mislukte, niet dat de kaart defect is. Above 4G Decoding is het eerste om te controleren.

Meerdere GPU’s en een ervan wil niet initialiseren. Dit is de multi-GPU- en AI-rig-faalmodus. Vier kaarten met BAR’s van 24GB hebben 96GB aan 64-bits MMIO-ruimte nodig, plus al het andere, en niet elke consumentenbordfirmware doet dat. Het symptoom is dat de machine prima is met twee kaarten en omvalt met vier.

De prestaties gingen omlaag. Op NVIDIA kan dat de eigen conclusie van de driver zijn, aangezien ze het per titel inschakelen juist omdat sommige workloads teruglopen. Op de andere: meet beide kanten in plaats van aan te nemen.

Er veranderde helemaal niets. De meest waarschijnlijke uitkomst voor een workload die nooit beperkt werd door het venster van de CPU op VRAM.

Een Large-BAR-GPU Doorgeven Aan Een VM

De moeite waard te vermelden omdat het mensen verrast: een gast erft de geheugenkaart van de host niet. De firmware van de VM bouwt zijn eigen 64-bits MMIO-venster, en de standaard van OVMF is veel kleiner dan een moderne GPU nodig heeft, dus de kaart faalt ofwel bij het initialiseren of valt terug op een kleine BAR. Dat is een Proxmox- en QEMU-onderwerp in plaats van een GPU-onderwerp, en het leeft in het IOMMU-tax-artikel naast de machinetype-vereisten uit Gebruik Altijd Q35, Niet i440fx.

Referenties

• Intel — Resizable BAR and Intel Arc Graphics — Intels eigen uitspraak dat het vereist is voor een goede ervaring op Arc, en de lijst met ondersteunde platforms
• NVIDIA — Resizable BAR support for GeForce RTX 30 Series — de vereisten, het gemeten bereik, en de aanpak met profielen per game
• AMD — Smart Access Memory — AMD’s branding en platformkoppeling
• Linux kernel sysfs-bus-pci ABI — resourceN_resize — de bitmap, de 2 ^ (bit + 20)-grootte, en de unbind-voorwaarden
• ROCm system requirements — de PCIe-atomics-vereiste die met deze wordt verward