Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Sorry falls das schon mal thematisiert wurde, aber da das Video erst ein paar Stunden alt ist, dachte ich, das könnte hier von Interesse sein:
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Hintergrund: Jay war frustriert, dass sein XOC-PC nicht annähernd an die Scores der Top-Leute herankam und bekam dann den Tipp bzgl Resizable Bar-Einstellungen im NV-Treiber (nur einstellbar via NV Profile Inspector).
Ich habe das natürlich gleich auch mal ausprobiert, alleine schon weil nicht klar war, ob das nur extreme High-End Konfigurationen betrifft oder ob Leute mit etwas weniger wahnsinniger Hardware hier auch profitieren können.
Während die Einstellungen vorher bei mir dieselben waren wie bei Jay (also rBAR im BIOS AN, aber laut NV-Inspector im Treiber deaktiviert), habe ich das gleich mal geändert und dann 3DMark laufen lassen. Meine Scores waren in den drei Tests die ich bisher habe laufen lassen zwar allesamt höher, aber außer in Port Royal war der Vorsprung mehr oder weniger trivial.
Timespy: +0,7 Prozent insgesamt, +0,8 Prozent GPU-Score
Speedway: +0,7 Prozent
Port Royal: 3,0 Prozent
In den Video Kommentaren war dann übrigens auch zu lesen, dass ein generelles Aktivieren des Features zu Problemen oder sogar Abstürzen in bestimmten Spiele führen kann. Evtl sollte man das also nicht im globalen Profil einschalten. Angeblich sind UE5-Titel besonders stark betroffen und mögen rBAR ON nicht.
Die interessante Frage ist doch. Warum fummelt nVidia da rum und schaltet es aus. Obwohl der User es im Bios aktiviert hat. Und warum braucht man bei nVidia ein extra Tool, um es doch zu aktivieren.
Erinnert an "Async-Compute" zu Beginn mit Pascal? "Wir können das zwar definitiv, aber wir machen das lieber aus, weil mit wird nichts schneller oder kackt ab".
Wenn das Feature eine hohe "Pro-Titel-Abhängigkeit" hat, stellt man das als Hersteller eben so sein, dass es am wenigsten Stress gibt.
Weil die meisten Leute nicht wirklich verstehen was ReBAR ist und nicht ist.
Klassisch haben GPUs ein BAR von ~256 MiB. Also stellen 256 MiB an Addressraum auf dem PCIe Bus bereit, auf den die CPU zugreifen kann.
Das war nie schlimm, weil man eh DMA nutzen will. Denn die allermeisten Datentransfers zwischen CPU und GPU finden nicht direkt statt (CPU-Kern sendet Lesebefehle oder Schreibfehle an die GPU und wartet auf Antwort, genau wie es bei RAM Zugriffen passiert).
Stattdessen, gibt es eine Warteschlange an Befehlen für die GPU, die von der GPU abgearbeitet wird. Die GPU macht also Zugriffe auf den System RAM (= Direct Memory Access). Das ist allgemein bei fast allem so. Es entlastet die CPU Kerne, weil jede Peripherie Ihre Zugriffe unabhängig im Hintergrund machen kann.
Moderne Systeme wären ohne DMA nicht möglich. Aber dass man den Befehl in die Warteschlange schreiben muss, warten muss bis die GPU den mitbekommt und dann ausführt kostet Latenz. Insbesondere kleine (keine großen Datenmengen) Zugriffe direkt zu machen spart Latenz, dafür kostet es mehr CPU Zeit.
Es gab in der Server-Welt auch schon ewig Karten mit größeren BARs. Xeon Phi Karten zB mit ihren 32 GiB RAM stellen den vollständig an PCIe bereit. Systeme die nicht genügend Adressraum haben dafür können schlicht nicht booten mit den Karten drin.
Deshalb gibt es ReBAR, damit die GPUs ihre traditionelle und rückwärtskompatible BARs angeben können, aber moderne Systeme (CPU, BIOS, OS) können das nachträglich ändern. Das ist alles was "ReBAR" selbst erlaubt. Es erlaubt GPUs ihren vollständigen VRAM direkt auf dem PCIe Bus sichtbar zu machen, ohne die Kompatibilität zu alten System zu brechen, die damit nicht umgehen könnten.
Das alleine aber ändert erstmal nichts. Bulk-Transfers, also mehrere GiB zu übertragen, müssen immer noch indirekt gemacht werden. Die top Transferraten kann man sonst gar nicht erreichen.
Den gesamten Adressraum zu mappen, ist nur Vorraussetzung, dass die CPU flexibel auf alle Bereiche auch direkt zugreifen könnte.
Wann dann genau direkte Zugriffe gemacht werden, musste quasi immer eine Heuristik sein. Denn man will nur genau kleine, latenzkritische Zugriffe direkt machen, wenn der CPU Kern, von dem der Zugriff ausgeht noch Zeit übrig hat dafür. Das ist etwas das Spiele einem so nicht wirklich sagen oder sicherstellen. Deshalb haben die Treiber pro Spiel Heuristiken, welche Transfers direkt umgesetzt werden können, weil es mit den meisten CPUs und den meisten GPUs mit erwarteter PCIe Bandbreite schneller wird. Und deshalb werden direkte Zugriffe auf VRAM hinter dem PCIe Bus auch immer eine Ausnahme bleiben. Die pauschal immer zu nutzen würde einfach Performance kosten.
ReBAR im BIOS sollte eigentlich nie ausgeschaltet werden brauchen, weil es nie schadet. Es stellt einfach nur den gesamten VRAM am PCIe Bus bereit, das war es. Das kann der Treiber nutzen für die fragile Latenzoptimierung mit direkten Zugriffen, muss aber überhaupt nicht. Im schlimmsten Fall macht das Spiel lauter kleine Zugriffe am Stück und diese würden in der Warteschlange gesammelt und dann effizient gesammelt ausgeführt. Während mit direkten Zugriffen jeder sofort rausgehauen wird und der CPU Kern sehr viel Zeit darauf verliert auf die Hardware zu warten. Wenn dann die Ankunft der Daten noch nicht mal Zeitkritisch war für das Spiel hat man gerade alles schlechter gemacht.
Deshalb muss es Regler für sowas im Treiber geben. Und deshalb ist das Nutzen direkter Zugriffe bei eGPUs zB auch oft kontraproduktiv. Weil die eingestellten Heuristiken nicht passen für externe GPUs, die sowieso schon eine höhere Latenz haben (wegen Zwischenschritten bei PCIe und der wesentlich geringeren Bandbreite) und eher mit schwachen CPU arbeiten, die weniger Zeit zu verschenken haben.
"ReBAR" der Name, wird leider gerne missbraucht als Name für die Heuristik zwischen direkten und indirekten Zugriffen, obwohl das eigentlich völlig unabhängig ist. Daher die Verwirrung. Was Nvidia im Treiber pro Spiel steuert ist eigentlich nicht "ReBAR".
Das einzige was man im Treiber die bezüglich machen könnte, wäre das OS nie den gesamten VRAM mappen zu lassen. Aber das hat gar keine Nachteile, wenn der Adressraum da ist. Deshalb könnt ihr ja mal im Gerätemanager schauen. Wenn ReBAR im BIOS an ist und der GPU Treiber / OS neu genug ist, wird die GPU mit gesamtem VRAM gemappt. Immer. Egal was du im Treiber einstellst.
Moderne CPUs haben teilweise 128 TiB an Adressraum für RAM und PCIe Bus. Die brauchen nur Platz lassen zwischen verschiedenen Dingen und dann ist das kein Problem. Meine Intel Platform reserviert zB 64 GiB Adressraum fúr jeden USB4-PCIe Port, den sie für später angesteckte PCie Geräte nutzen könnte. Alte Desktop Platformen mit altem TB4 Controller haben dort nur 1,5 GiB reserviert, für 2 Ports.
Und meine neue AMD Platform reserviert 1 TiB oder so für jeden USB4-PCIe Port, weil Adressraum im absoluten Überfluss da ist.
Ergänzung ()
Das zeigt, das ReBAR genutzt wurde beim Booten. Denn die GPU hat 0x60_0000_0000 - 0x67_FFFF_FFFF Bytes an Addressraum = 32 GiB. Was bei einer normalen GPU nur mit ReBAR machbar ist, denn die angegebenen BAR Größen hören eben bei 256 MiB auf damit die rückwärtskompatibel sind.
Deshalb hängt mit ReBAR im BIOS auch immer die "Above 4G Decode" Option zusammen. Denn die steuert ob der PCIe Bus überhaupt 64 Bit Adressen nutzen kann oder bei 32 Bit Adressen bleiben muss (32 bit = 4 GiB Adressraum).
Alles was man im Profile Inspector einstellt, stellt eigentlich etwas ganz anderes ein. Hier ist der Name schlichtweg falsch.
Edit2: und bis man die GPU Runtime Schnittstellen so aufbohrt, dass die Anwendung immer angibt, wie Latenzkritisch eine kleine ÜBertragung ist und das OS angibt, wie viel CPU Zeit man noch gegen mehr Performance eintauschen könnte, wird sowas eine Heuristik bleiben müssen. Und auf ein ganz spezifisches System, erst recht noch mit starker Übertaktung (also weiter weg von Werkseinstellungen), kann man garantiert immer noch feinfühlig weiter optimieren. Da das aber Heuristiken sind, ist das nicht unbedingt allgemeingültig, auf andere Maschinen übertragbar oder vllt auch gar nicht die Schuld von Nvidia.
Das ganze GPU Treiber Profil Zeugs ist die GPU Hersteller versuchen mehr Performance herauszupressen, an Stellen wo die eigentliche Software nur unzureichend auf die gegebene Hardware optimiert wurde. Und das hat teilweise System, weil es viel zu viel Hardwarevarianten gibt, als dass alle gut abgedeckt werden könnten. Oder die Hardware erst nach der Software herauskam und die Software nicht mehr gewartet wird.
Ich sollte den Video-Link oder den ganzen Thread wohl löschen, da Jay hier mal wieder Schwachsinn erzählt haben könnte, um ein paar Klicks einzusammeln. Tom's HW hat das dann übrigens gleich mal in einer News-Meldung nachgeplappert, um sich auch noch ein paar Klicks zu sichern.
Ich lasse das erst einmal einfach stehen, damit die Diskussion erhalten bleibt, und der Thread weiterhin "nachvollziehbar" ist.
Wenigstens der Vorschlag den reBAR-Eintrag im allgemeinen Treiber-/NV-Profil generell zu aktivieren scheint nach allem was ich gelesen habe ziemlicher Schwachsinn zu sein. In einigen Anwendungsszenarien kann das sogar zu schlechterer Performance führen - von Instabilität und Abstürzen ganz zu schweigen.
