Was ein BAR ist, und warum GPUs daraus herausgewachsen sind
Jedes PCIe-Gerät legt ein oder mehrere Base Address Register offen. Ein BAR sagt dem System, wie viel Adressraum das Gerät haben will, und die Firmware bildet ihn in die Speicherkarte des Hosts ab. Ist er abgebildet, erreicht die CPU den Speicher des Geräts mit gewöhnlichen Lade- und Speicherbefehlen.
Die Größe eines BAR war früher im Silizium festgelegt. Die Firmware las sie beim Einschalten, und damit war das Gespräch beendet.
Das war in Ordnung, solange BARs klein waren. Eine Netzwerkkarte will ein paar Dutzend Kilobyte für ihre Register. Ein NVMe-Controller will 16 KB bis 64 KB.
Grafikkarten haben die Sache gesprengt. Eine moderne Karte hat 8, 12, 16 oder 24 GB Videospeicher, und das Naheliegende ist, alles abzubilden, damit die CPU überall hineinschreiben kann. Feste BARs konnten das nicht ausdrücken, also wurde ein kleines Fenster zur Übereinkunft — üblich 256 MB —, das der Treiber über den Framebuffer verschiebt und stückweise durchkopiert. Es funktioniert. Es ist bloß eine dämliche Menge Buchhaltung, um an Speicher zu kommen, den du schon gekauft und eingebaut hast.
Was Resizable BAR ändert
Resizable BAR ist eine PCIe-Fähigkeit, mit der die Größe eines BAR verhandelt statt festgelegt wird. Das Gerät gibt an, welche Größen es kann, und die Firmware oder das Betriebssystem programmiert eine davon.
Für eine GPU heißt das, dass der ganze Framebuffer auf einmal abgebildet werden kann.
Der Treiber hört auf, durch ein Fenster zu blättern, und schreibt dorthin, wohin er schreiben will.
Der Kernel meldet die Fähigkeit als Physical Resizable BAR, und sie ist herstellerneutral. Eine AMD-Karte arbeitet damit auf einer Intel-Plattform und umgekehrt.
Was die drei Hersteller tatsächlich tun
Das Interessante ist, dass die Hersteller sich nicht einig sind, wie viel es ausmacht.
Intel Arc und Arc Pro — Intel nennt es zwingend
Intel ist der Nachdrückliche. Ihre Hinweise sagen, Resizable BAR sei „required to get a good experience with Intel® Arc™ hardware“ — nötig, um mit Intel-Arc-Hardware eine gute Erfahrung zu bekommen. Das ist für ein Plattformmerkmal ungewöhnlich starke Sprache, und sie zeigt, wie der Arc-Treiber gebaut ist, nicht eine Marketing-Entscheidung.
Auf der Symptomseite beschreibt Intel die Wirkung des Abschaltens nicht in Durchschnitten, sondern in Gleichmäßigkeit: mit „ReBAR off“ werde es „generally result in spikes that were already there getting bigger“ — Spitzen, die schon da waren, werden größer. Das ist ein Argument über die Stabilität der Bildzeiten, und es hat dieselbe Form wie die Wirkung von ASPM auf Latenzausläufer. Der Durchschnitt verbirgt sie.
Intel führt Intel-Core-Prozessoren der 10. Generation und neuer, die meisten Ryzen der 3000er-Reihe und alle Ryzen-5000-CPUs als unterstützte Plattformen und behandelt es als BIOS-Funktion des Mainboards, die du selbst einschalten musst.
Für Arc und Arc Pro ist die praktische Folge einfach. Hast du eine Arc-Karte in eine Maschine gesteckt und die Leistung ist enttäuschend oder ungleichmäßig, prüf das, bevor du irgendetwas anderes prüfst. Damit ist es auf diesen Karten weniger ein Stellrad als eine Voraussetzung.
NVIDIA — ab Ampere, und nur wo es hilft
NVIDIA hat die Unterstützung für Karten und Laptops der GeForce-RTX-30-Reihe im März 2021 nachgeliefert. Damit es lief, brauchte es ein passendes VBIOS, eine passende CPU und Platine, eine Aktualisierung der Platinen-Firmware und einen aktuellen Treiber. Die RTX 3060 kam damit; die 3060 Ti, 3070, 3080 und 3090 konnten eine Firmware-Aktualisierung brauchen.
NVIDIAs eigene Einordnung der Leistung ist erfreulich unglamourös. Sie fanden, dass „some titles benefit from a few percent, up to 12%“ — manche Titel profitieren um wenige Prozent, bis zu 12 % —, während „there are also titles that see a decrease in performance“, es also auch Titel gibt, bei denen die Leistung sinkt.
Ihre Antwort darauf ist die Einzelheit, die man kennen sollte: statt es global anzulassen, testet NVIDIA Titel vorab und schaltet Resizable BAR über Profile pro Spiel nur dort ein, wo es als Gewinn gemessen wurde. Auf einer NVIDIA-Karte hat „ist ReBAR an?“ also eine Antwort pro Anwendung, und ein Benchmark, der nichts zeigt, kann einfach ein Titel sein, den der Treiber in Ruhe gelassen hat.
AMD — Smart Access Memory ist dasselbe
AMDs Markenname dafür ist Smart Access Memory, eingeführt zusammen mit der Radeon-RX-6000-Reihe und den Ryzen-5000-CPUs. Das Marketing legt eine Paarung aus AMD-CPU und AMD-GPU nahe, und so wurde es auch gestartet, aber die Fähigkeit darunter ist die normale PCIe-Fähigkeit. Schalte Resizable BAR in der Firmware mit einer Radeon-Karte in einer Intel-Maschine ein, und du bekommst dieselbe Funktion ohne den Markennamen.
Radeon-Pro-Karten der W-Reihe können es auch. Auf älteren Architekturen — Vega und Polaris — ist die Unterstützung lückenhafter, und dort wohnt auch der Ärger mit der Virtualisierung.
Resizable BAR und KI-Arbeit
Hier wird die Funktion missverstanden, deshalb lohnt es sich, klar zu sagen, was sie anfasst.
Resizable BAR ändert, wie die CPU an den GPU-Speicher kommt. Das ist der Übertragungsweg — Modellgewichte bereitstellen, Batches hineinschieben, Ergebnisse zurücklesen. Es fasst die Speicherbandbreite der GPU selbst nicht an, und es macht keine Matrixmultiplikation schneller.
Die ehrliche Zusammenfassung ist also, dass es das Laden und Füttern eines Modells betrifft, nicht die Arithmetik. Bei einem großen Modell ist die Kopie vom Host zum Gerät beim Laden ein echter Kostenposten, und ein BAR in voller Größe lässt die CPU direkt in den Gerätespeicher schreiben, statt durch ein Bullauge von 256 MB zu pendeln. Für den Dauerzustand eines Inferenzlaufs — wo die Gewichte schon liegen und die Arbeit rechengebunden ist. Erwarte nichts.
Drei Punkte lohnen sich.
Arc Pro für KI erbt Intels Urteil. Wenn Intel sagt, die Karte braucht Resizable BAR für eine gute Erfahrung, gilt das für eine Karte mit oneAPI oder PyTorch genauso wie für eine mit einem Spiel. Arc- und Arc-Pro-Karten, die Inferenz machen, sollten es eingeschaltet haben, Punkt.
Bei NVIDIA ist die Zahl, die du willst, BAR1. BAR1 ist das für den Host sichtbare Fenster auf den Gerätespeicher, und darüber laufen Host-abgebildete Allokationen und GPUDirect RDMA:
# How much device memory is actually host-visible
nvidia-smi -q | grep -A3 "BAR1 Memory Usage"
Eine Rechenzentrumskarte ist mit einem großen BAR1 gebaut. Auf einer Desktop-Karte ist Resizable BAR das, was dieses Fenster groß statt winzig macht. Machst du RDMA direkt von einer NIC in den GPU-Speicher, ist das keine Feinheit.
Verwechsle das nicht mit der Anforderung von ROCm. AMDs Systemanforderungen für ROCm verlangen CPUs mit PCIe-Atomics — „modern CPUs after the release of 1st generation AMD Zen CPU and Intel™ Haswell“ — und sagen nichts über BAR-Größen. Das sind zwei verschiedene Plattformanforderungen, die im selben BIOS-Menü wohnen, und Leute werfen sie ständig zusammen. Prüf die, die du wirklich brauchst.
Der Fehlerfall, der KI-Aufbauten am härtesten trifft, ist überhaupt keine Leistungsfrage, und er steht weiter unten: mehrere GPUs mit großem BAR in einer Maschine können den Adressraum leerlaufen lassen.
Was es zum Funktionieren braucht
Vier Dinge, und alle auf Firmware-Ebene:
- Resizable BAR eingeschaltet in der Mainboard-Firmware. Oft standardmäßig aus.
- Above 4G Decoding eingeschaltet. Ein BAR von 24 GB passt nicht unter die 4-GB-Linie, die Plattform muss also bereit sein, Adressraum darüber zu vergeben. Schalte das auch ohne GPU ein. Es kostet nichts.
- UEFI-Start, mit CSM aus. Der Kompatibilitätsmodus und große BARs verstehen sich nicht.
- Aktuelle Firmware und Treiber, besonders auf den Platinen und Karten aus dem Übergang 2020–2021, wo die Unterstützung per Aktualisierung statt zum Start kam.
Wie man es unter Linux prüft
Ob die Karte die Fähigkeit hat, und welche Größen sie anbietet:
# Substitute your card's address from lspci
lspci -vvs 0000:XX:00.0 | grep -A6 "Physical Resizable BAR"
Der Kernel legt das auch in sysfs offen, eine Datei pro veränderbarem BAR:
cat /sys/bus/pci/devices/0000:XX:00.0/resource1_resize
Dieser Wert ist eine Bitmaske der möglichen Größen, keine Größe.
Bit 0 heißt 1 MB, Bit 1 heißt 2 MB, Bit 2 heißt 4 MB, und die Größe für ein Bit ist 2 ^ (Bit + 20).
00000000000001c0 hat also die Bits 6, 7 und 8 gesetzt, das BAR kann demnach 64 MB, 128 MB oder 256 MB sein.
Um zu sehen, was tatsächlich gilt, lies die zugewiesenen Regionen:
lspci -vvs 0000:XX:00.0 | grep -i Region
Eine Karte, die mit ihrem ganzen Framebuffer abgebildet läuft, zeigt eine Region in der Größe ihres VRAM statt einer von 256 MB.
Von Hand vergrößern
Du kannst die Bitposition selbst schreiben:
# bit 7 -> 2 ^ (7 + 20) = 128MB
echo 7 > /sys/bus/pci/devices/0000:XX:00.0/resource1_resize
Die Bedingungen daran sind streng und es lohnt, sie zu lesen, bevor du es an einer Maschine versuchst, die dir am Herzen liegt.
Jeder Treiber muss zuerst vom Gerät gelöst werden.
Nachbargeräte unter derselben übergeordneten Bridge müssen möglicherweise sanft entfernt werden.
Auf einem VGA-Gerät reißt das Schreiben eines Größenwerts die Konsolentreiber der unteren Ebene ab.
Alles, was die resourceN-Dateien in sysfs offen hält, muss loslassen.
Die Kernel-Dokumentation ist über das Ergebnis auch unmissverständlich: Erfolg ist nicht garantiert. Das Vergrößern scheitert, wenn kein Adressraum für das größere BAR da ist. Was dich direkt zurück zu Above 4G Decoding bringt.
Wenn es schiefgeht
dmesg sagt, es kann das BAR nicht zuweisen.
Meldungen in der Form BAR 0: no space for [mem size ...] heißen, dass die Zuweisung gescheitert ist, nicht dass die Karte kaputt ist.
Above 4G Decoding ist das Erste, was man prüft.
Mehrere GPUs, und eine kommt nicht hoch. Das ist der Fehlerfall bei mehreren GPUs und in KI-Kisten. Vier Karten mit BARs von 24 GB brauchen 96 GB an 64-Bit-MMIO-Raum, plus alles andere, und nicht jede Firmware einer Consumer-Platine macht das mit. Das Symptom ist, dass die Maschine mit zwei Karten läuft und mit vier umfällt.
Die Leistung ist gesunken. Bei NVIDIA kann das der Schluss des Treibers selbst sein, denn sie schalten es genau deshalb pro Titel ein, weil manche Lasten zurückfallen. Bei den anderen: messen statt annehmen, und zwar in beide Richtungen.
Es hat sich überhaupt nichts geändert. Das wahrscheinlichste Ergebnis bei einer Last, die nie vom Fenster der CPU in den VRAM begrenzt war.
Eine GPU mit großem BAR an eine VM durchreichen
Erwähnenswert, weil es Leute überrascht: ein Gast erbt die Speicherkarte des Hosts nicht. Die Firmware der VM baut ihr eigenes 64-Bit-MMIO-Fenster, und die Voreinstellung von OVMF ist weit kleiner, als eine moderne GPU braucht, die Karte kommt also entweder nicht hoch oder fällt auf ein kleines BAR zurück. Das ist ein Proxmox- und QEMU-Thema und kein GPU-Thema, und es wohnt in dem Beitrag über die IOMMU-Steuer neben den Anforderungen an den Maschinentyp aus Immer Q35, nicht i440fx.
Quellen
- Intel — Resizable BAR and Intel Arc Graphics — Intels eigene Aussage, dass es auf Arc für eine gute Erfahrung nötig ist, und die Liste der unterstützten Plattformen
- NVIDIA — Resizable BAR support for GeForce RTX 30 Series — die Anforderungen, die gemessene Spanne und der Ansatz mit Profilen pro Spiel
- AMD — Smart Access Memory — AMDs Markenname und die Plattformpaarung
- Linux-Kernel-ABI sysfs-bus-pci —
resourceN_resize— die Bitmaske, die Größe als2 ^ (Bit + 20)und die Bedingungen zum Lösen der Treiber - ROCm-Systemanforderungen — die Anforderung an PCIe-Atomics, die mit dieser hier verwechselt wird