Frage RBar

Basics2310

Lieutenant
Registriert
Juni 2011
Beiträge
827
Hallo guten Abend , mal eine Frage zu Rbar im Bios.
Bringt Rbar nur was bei Games oder ist es auch bei anderen Anwendungen Sinnvoll?
Vielen Dank
 
An welche Anwendungen denkst Du?
Ergänzung ()

Oder anders: ja.

Bei jeder Anwendung welche von einer Spiele-ähnlichen Optimierung profitiert.
 
Danke, denke an Videoschnitt (premiere) und Bildbea (Photoshop)
 
Basics2310 schrieb:
Bringt Rbar nur was bei Games oder ist es auch bei anderen Anwendungen Sinnvoll?
ReBar ist erstmal nur eine Technik um PCIe Karten zu erlauben große Mengen an Addressraum zu mappen, ohne die Kompatibilität zu alten Betriebsystemen und alten Hosts zu brechen, die so viel Addressraum nicht haben.

Das Feature um dass es sich also eigentlich dreht für eine GPU ist ob der VRAM der GPU vollständig in den Adressraum der CPU gemappt wird (die CPU kann auf jedes Byte im VRAM direkt zugreifen, durch Benennung der spezifischen Adresse in normalen Speicherzugriffen, was klassischerweise nicht geht).

Auf der anderen Seite war das lange aus gutem Grund irrelevant. Weil allgemein willst du nicht, dass die CPU alle Datentransfers zwischen VRAM und RAM des Systems explizit macht. Was man normalerweise will ist der GPU / dem PCIe Gerät einen Befehl geben. Und das Gerät macht dann den Zugriff autonom (vgl. DMA), indem das PCIe Gerät direkt mit dem Memory Controller kommuniziert und die eigentlichen CPU Kerne müssen sich nicht damit beschäftigen.

Nachteil ist, für kleine, latenzkritische Zugriffe ist es unter Umständen ineffizienter, weil du dem PCIe Gerät einen Befehl geben muss und dann initiert das PCIe Gerät erst den eigentlichen Speicherzugriff (Daten von VRAM in den RAM kopieren oder umgekehrt).

Edit:
Also ein feinfühliger Tradeoff, ob Latenz oder CPU-Last / Datenrate gerade wichtiger ist. Was sich von Zugriff zu Zugriff unterscheiden kann. Spiele mit hohen Refreshrates sind hier klassischerweise am Latenzkritischsten. Weil sie brauchen Nutzereingaben und müssen diese dann so schnell wie möglich durch die Verarbeitungskette bis zur GPU schieben. Alles was nicht so sehr an Nutzereingaben hängt oder vorhersehbarer / planbarer ist profitiert davon eher weniger und lässt die Nachteile überwiegen.
/Edit

Andere Programme können also durchaus auch davon profitieren, wenn sie viele kleine, latenzkritische Zugriffe machen.

Allerdings sollten die GPU Treiber hier auch stark involviert sein und für jeden Datentransfer entscheiden, welche Art von Zugriff wohl besser sein wird. Hier haben die Treiber für Spiele oft vorgefertigte Konfigurationen die sagen, dass eine ist immer schlechter als das andere etc. Ich habe keine Ahnung ob die APIs die Programme nutzen, den Programmen die Möglichkeit geben die Umsetzung von einem Datentransfer explizit zu verlangen oder anderweitig Kontrolle haben was gemacht wird oder ob der Treiber einfach immer macht was er will / für richtig hält. Also der Treiber und die Software hat am meisten Einfluss, ob die neuen Möglichkeiten die man durch ReBar hat überhaupt genutzt werden.

Und man könnte das ganze auch ohne ReBar haben, wenn man einfach auf die Rückwärtskompatibilität zu alten Systemen verzichten würde. Wobei es da viele Nischen gibt, wo der Addressraum dann doch nicht da ist, obwohl das System es grundsätzlich könnte... (Thunderbolt eGPUs zB).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Herdware, CoMo, Falc410 und 14 andere
Ein weiterer Vorteil von RBar ist, dass die Paketgröße deutlich angehoben wurde.
Statt viele kleine Datenhäpchen werden größere zur Grafikkarte geschickt was den PCI-E Overhead verkleinert.
 
wern001 schrieb:
Ein weiterer Vorteil von RBar ist, dass die Paketgröße deutlich angehoben wurde.
Das ist nicht korrekt, Resizable Bars fasst die PCIe-Paketgrößen nicht an. Hinzugefügt wurde die Möglichkeit BARs größer als 256MB zu gestalten, was es der CPU ermöglicht auf den gesamten Framebuffer von GPUs auf einmal zuzugreifen (Quellen: wiki, Intel).
Also um 3 Ecken reduziert sich unter Umständen tatsächlich der PCIe-Overhead, aber nicht bei Paketgrößen.
 
SoDaTierchen schrieb:
Hinzugefügt wurde die Möglichkeit BARs größer als 256MB zu gestalten
Wie gesagt, sogar dass ging schon die ganze Zeit ganz ohne ReBar. ReBar gibt dem System auf Umwegen quasi mehrere BAR-Größen, so dass das System auswählen kann, was ihm am besten passt. Und die Auswahl passiert auch erst nachträglich vom Betriebssystem, wenn es weiß dass es sicher damit umgehen kann und will.

Wir hatten auf der Arbeit mal die alten Xeon-Phi PCIe Karten. Und die stellen einfach ihre gesamten (waren es 16 GiB RAM?) via PCIe bereit. Dauerhaft.

Und der Server in dem die stecken limitiert ab Werk auf 32 Bit PCIe Adressierung (also max 4 GiB. Die bekannte BIOS Option "above 4G decoding", die oft eine Voraussetzung für ReBar ist, war da aus) und dann kriegt man nur eine Fehlermeldung vom BIOS in der Art "PCIe Cards are exceeding available memory. Remove the cards and reboot to restore the system".

Der einzige Grund für ReBar ist, dass die GPUs weiterhin die klassischen 256 MiB angeben können, die alle Systeme, auch reine 32 Bit Systeme zuverlässig können. Und zusätzlich dann die vollen Größen, die nur auf modernen Systemen mit riesigem PCIe Adressraum gehen. Und hinter PCIe Bridges wie Thunderbolt / USB4 geht das zB immer noch nicht. Da ist man oft noch auf 500-700 MiB Adressraum beschränkt und GPUs die einfach Gibibytes an BARs angeben, würden einfach nicht gehen.
 
Zuletzt bearbeitet:
Zurück
Oben