News AMD Smart Access Memory: Resizable BAR macht auch unter Linux Fortschritte

[SVΞN]

Nicht nur unter Windows ist AMD Smart Access Memory ein großes Thema, auch unter Linux macht der offene Standard Resizable BAR weiter Fortschritte. Nachdem zuletzt der offizielle Open-Source-Treiber „RadeonSI“ erste Optimierungen für den offenen Standard erhalten hat, zieht jetzt auch „RADV“, der Treiber für Vulkan, nach.

Zur News: AMD Smart Access Memory: Resizable BAR macht auch unter Linux Fortschritte

 

[Moep89]

Eine Meldung nach der anderen zu dem Thema, aber leider nützt die theoretische Möglichkeit nichts. Man ist auf das Wohlwollen der Mainboardhersteller angewiesen. Ob die jedoch für die große Masse der Nutzer, die kein Board aus den letzten 2 Jahren nutzen noch etwas tun ist höchst fraglich. So bleiben am Ende viele Nutzer außen vor, obwohl der Standard schon uralt ist. Mir würde es mit meiner RX5700XT sicher einiges bringen, mein i7 8700 dürfte es können, aber das Board kriegt wohl kein Update um den Startschuss zu geben.

 

[Falc410]

Ein Standard aus 2008 - 12 Jahre alt und erst jetzt wird er von AMD aufgegriffen und implementiert. Ich finde es zwar schön, dass sie das machen aber ich frage mich echt warum die letzten 12 Jahre niemand auf die Idee gekommen, das zu implementieren - also in früheren NVIDIA oder AMD Generationen.

 

[Rickmer]

@Falc410 meine Perspektive - nvidia hasst nicht-proprietäre Standards zu sehr und AMD hatte bis vor sehr kurzem kein Geld um die nötige Software dazu zu schreiben

 

[foo_1337]

Ich hatte es im anderen Thread letztens schon geschrieben. Intel unterstützt es auf den Consumer CPUs seit Haswell, also 2013 (7 anstatt 12 Jahre). Spätestens seit 2017 gibt es erste Implementationen im amdgpu drm Modul. Damals war es jedoch unmöglich zu testen, da der BIOS bzw. UEFI Support fehlte. Intel hatte kein großes Interesse daran das im Consumer Bereich richtung Mainboard Hersteller zu Pushen. AMD hat mittlerweile durch den Zen Erfolg jedoch einen großen Einfluss auf die Mainboard Hersteller und konnte sie daher "zwingen", das nun zu implementieren.

 

[Forlorn]

Sobald das Update von Mesa bei Fedora kommt, werde ich das mal testen. Lustig wäre es, wenn dann ein Spiel unter Linux/Wine mit DXVK und BAR schneller läuft als unter Windows (weil das für meine Graka unter Windows noch nicht freigegeben ist).

 

[foo_1337]

weil das für meine Graka unter Windows noch nicht freigegeben ist)

Ist es. Wird aber vermutlich wenig bis nichts bringen.

 

[dasbene]

...AMD hatte bis vor sehr kurzem kein Geld um die nötige Software dazu zu schreiben

Genau das. In den letzten 12-13 Jahren in denen ich mich mit Hardware beschäftigt habe ging es AMD fast immer finanziell schlecht. Die mussten ja schon von Fabs bis zum Hauptquatier alles verkaufen bei den regelmäßigen Verlusten.
Deswegen kann ich auch nicht verstehen warum die Leute immer wieder mit Vorwürfen ankommen warum AMD etwas nicht hat/macht was Intel oder Nvidia hat.

 

[holdes]

Hmm je öfter ihr darüber eine News bringt desto mehr würde es mich doch mal anfixen zu testen aber HEDT scheint ja die Boardhersteller dahingehend nicht zu interessieren.

 

[SFFox]

Ein Standard aus 2008 - 12 Jahre alt und erst jetzt wird er von AMD aufgegriffen und implementiert. Ich finde es zwar schön, dass sie das machen aber ich frage mich echt warum die letzten 12 Jahre niemand auf die Idee gekommen, das zu implementieren - also in früheren NVIDIA oder AMD Generationen.

Ich denke das ist ganz einfach zu begründen. Es kostet Aufwand. Der Nutzen derzeit bei einer Speichergröße von mehr als 10GB beträgt im beste case ~13% Mehrleistung, für gewöhnlich fällt es aber sehr viel geringer aus. Bei geringerer VRAM Größe reduziert sich die Mehrleistung durch das Feature bestimmt noch mehr. Es hat sich also nicht gelohnt da groß Arbeit rein zu stecken für minimale Fortschritte.
Texturen / Grafikdaten haben eine Größe erreicht in Spielen, wo der ehemalige "Aperture Size" von max. 256 MB zum Flaschenhals geworden ist. Das war in den letzten Jahren wohl einfach noch nicht der Fall, um die Arbeit an dem Feature zu rechtfertigen.

 

[Forlorn]

Ist es.

Nicht mitbekommen, danke!

 

[Bierliebhaber]

Wie funktioniert eigentlich SAM, nutzt die CPU dann die Daten, die die GPU im Speicher hat, oder kann sie auf den VRAM zugreifen, der frei ist?
Konkret: Cyberpunk nutzt bei meiner 3070 schon 7,5GB. Wenn nVidia jetzt ebenfalls sowas integriert, gibts in solchen Fällen theoretisch auch ein plus (wenn z.B. meine erste Annahme zutrifft) oder profitiert man nicht (weil der VRAM schon zu voll ist)? Würde eine kleine Rolle spielen, ob ich nicht doch lieber auf eine 6800 sidegrade.

Ansonsten gut, dass es voran geht, ganz egal wie lange es bisher gedauert hat. Was da ist ist da. Gratis-Leistung, mit der man vor der Vorstellung von SAM nie gerechnet hat. Passt!

 

[foo_1337]

@Bierliebhaber Die CPU muss für diverse Instruktionen auf den VRAM zugreifen. Ohne den Resize der VRAM Bar funktioniert der CPU Zugriff immer nur mit 256MB Chunks. Mit Hilfe von SAM kann die CPU den VRAM nun voll adressieren. An der VRAM Usage sollte sich daher nichts ändern.

 

[el osito]

Dann war mein Test mit AC:O ja total für den Poppes, wenn das jetzt erst drin ist. 🙄

 

[Bierliebhaber]

@foo_1337 Danke! Das mit den 256MB war mir klar, ich wusste nur nicht, ob diese 256MB Daten der GPU oder Extradaten betrifft, die quasi die CPU in VRAM legt, und die CPU nur davon profitiert, dass sie Zugriff auf mehr sehr schnellen Speicher hat... technisch sicher mies ausgedrückt, mir aber egal, solange auch 3070-Käufer profitieren, je nach Spiel.

 

[wuest3nfuchs]

APUs funktionieren damit nicht hab auch ich schon probiert aber mit der R9 Fury geht's.

Mein Ergebnis:
https://www.computerbase.de/forum/t...test-mit-radeon-rx-6800.1992588/post-25103851

 

[bad_sign]

Ich denke das ist ganz einfach zu begründen. Es kostet Aufwand. Der Nutzen derzeit bei einer Speichergröße von mehr als 10GB beträgt im beste case ~13% Mehrleistung, für gewöhnlich fällt es aber sehr viel geringer aus. Bei geringerer VRAM Größe reduziert sich die Mehrleistung durch das Feature bestimmt noch mehr. Es hat sich also nicht gelohnt da groß Arbeit rein zu stecken für minimale Fortschritte.
Texturen / Grafikdaten haben eine Größe erreicht in Spielen, wo der ehemalige "Aperture Size" von max. 256 MB zum Flaschenhals geworden ist. Das war in den letzten Jahren wohl einfach noch nicht der Fall, um die Arbeit an dem Feature zu rechtfertigen.

Im entsprechenden Artikel von Sven sind Boosts von >100% bei den min FPS drin, also von wenig kann hier nicht die rede sein.
Da ist sicherlich auch die Messgenauigkeit der User Mitschuld.
Wirkt aber nicht bei allen Games.

 

[0x8100]

Man ist auf das Wohlwollen der Mainboardhersteller angewiesen.

nicht unter linux. habe hier ein b450/3700x/vega56 sowie b450/2700/rx480 system, die im bios zwar "above 4g decoding" aber kein "sam" haben. unter linux ist rbar aktiv, unter windows nicht.

 

[morb]

Ich finde es echt gut was AMD und nVidia in den letzten Jahren durchgebracht haben... Raytracing und Low Level API sind die Dinge, die am prominentesten diskutiert werden. Resizable Bar und DLSS sind aber auch einfach super Entwicklungen.

Zum Offtopic Verfügbarkeit:
Ja stimmt, aber mei, wenn man wirklich will, und den Aufwand nicht scheut, findet man immer mal wieder was. Irgendwer hatte hier mal ne Telegram-Gruppe gepostet, da hab ich auch mein Zeug her. Unglaublich wie viele Nachrichten es da drin gab, zu CPUs und GPUs. Aber es is definitiv Aufwand und man muss schnell sein. Wer n Ferrari für n Butterbrot will hat momentan schlechte Karten...

 

[Moep89]

@0x8100 Sehr imteressant. Dann wäre ja die Frage, wo bzw. durch wen/was das Feature eigtl. aktiviert wird. Wenn das Board es nicht im EFI unterstützen muss, dann bliebe ja nur noch das OS. Das ergibt aber keinen Sinn, da ja die Boardhersteller Updates liefern. Hätte das MS in Windows einfach aktivieren können, hätten die sich das ja alle sparen können.

@SV3N Habt ihr da genauere Infos?

@morb Du meinst wohl eher wer einen Golf zum Listenpreis will.