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

Schade, irgendwas scheint nicht richtig im UEFI zu sein. Wo findet man BAR bei GigaByte?

Code:
AMD_DEBUG=info glxinfo | grep vram
    vram_size = 6144 MB
    vram_vis_size = 256 MB
    vram_type = 9
    vram_bit_width = 192
    has_dedicated_vram = 1

dmesg | grep BAR
[    0.224019] pci 0000:0c:00.0: BAR 0: assigned to efifb
[    5.673350] amdgpu 0000:0c:00.0: BAR 2: releasing [mem 0x7ff0000000-0x7ff01fffff 64bit pref]
[    5.673351] amdgpu 0000:0c:00.0: BAR 0: releasing [mem 0x7fe0000000-0x7fefffffff 64bit pref]
[    5.673434] [drm:amdgpu_device_resize_fb_bar [amdgpu]] *ERROR* Problem resizing BAR0 (-22).
[    5.673437] amdgpu 0000:0c:00.0: BAR 0: assigned [mem 0x7fe0000000-0x7fefffffff 64bit pref]
[    5.673445] amdgpu 0000:0c:00.0: BAR 2: assigned [mem 0x7ff0000000-0x7ff01fffff 64bit pref]
[    5.673464] [drm] Detected VRAM RAM=6128M, BAR=256M

Nachtrag: BAR war in F11c drin, aber ist in F11n wieder rausgeflogen. F11p hat es jetzt wieder. Aber im Moment habe ich keine Probleme mit dem Bios, die früheren Versionen haben immer mit dem RAM gezickt.
 
Zuletzt bearbeitet:
@Forlorn Hast du CSM deaktiviert und above 4G decoding aktiviert?

@Jesterfox Spielst du damit auf The Witcher an? Bei Gamerworks bekommen die Entwickler die Sourcen. CDPR hat ja dann auch später die Tesselationstufen anpassbar gemacht. Die AMD Karten hatten damals halt eine Tesselation Schwäche (in hohen Stufen). Das hatte erstmal nichts mit Böswilligkeit von Nvidia zu tun.
Ansonsten lies mal bitte noch das hier durch:
https://www.computerbase.de/forum/t...n-der-pc-sie-denn-packt.1988479/post-25011923
 
foo_1337 schrieb:
@Jesterfox Spielst du damit auf The Witcher an?
Das war eines der Beispiele, aber wenn ich mich recht erinner nicht das einzige. AMD hat ja extra nen optimierungs-Modus in die Treiber eingebaut der den Tesselation-Faktor überschreibt...

Und das von AMD war keine "Schwäche", die Leistung war absolut ausreichend. NV hatte zwar deutlich mehr Leistung, die brachte aber keinen Vorteil bei der Darstellung... man konnte damit aber AMD schlecht dastehen lassen...
 
Dass nvidia mit Gameworks schlecht dastehen lassen will, wird leider immer wieder behauptet.
https://developer.nvidia.com/gameworks-source-github
AMD kann zum einen den Treiber dahingehend optimieren sowie Patches einreichen.
Hast du den von mir verlinkten Beitrag von @.Sentinel. und seine Verlinkungen schon durchgelesen?
Was ist eigentlich mit den Powered by Radeon Spielen, bei denen die RX6800 Karten besser dastehen? Macht AMD das da auch nur um nvidia schlecht dastehen zu lassen?
Und genau so wird auch ständig behauptet, dass nvidia eine proprietäre Implementation hätte und mit absicht AMD hier schlecht dastehen lässt weil diverse RT Spiele damit angeblich nicht funktionieren. Der Name dieser Implementation soll "RTX" sein ;)
Damit sind vermutlich die nvidia vulkan extensions gemeint. Diese waren nie proprietär und AMD hätte diese supporten können, wenn sie denn gewollt hätte. Aber stattdessen hat das böse Nvidia, das ja immer anderen was schlechtes will, Q2 RTX auf die neue API portiert und es somit auch auf RX6x00 lauffähig gemacht. Und nicht nur das: Sie weisen AMD auch noch auf Fehler in ihrer Implementation hin: https://github.com/NVIDIA/Q2RTX/issues/99
 
foo_1337 schrieb:
Hast du den von mir verlinkten Beitrag von @.Sentinel. und seine Verlinkungen schon durchgelesen?
Jepp, hab ich. Klar kann es auch sein dass diese Fälle wo AMD schlechter gestellt wurde an der Unfähigkeit der Spielehersteller lag... aber bei der Menge stellt man sich halt doch die Frage ob es wirklich so war... es gab da ja auch dieses AC wo die DX Erweiterung wieder ausgebaut wurde, Project Cars lief auch eher mies auf AMD usw.

In Summe wirkt es einfach so und NVidia macht irgendwie auch nichts um es anders wirken zu lassen...
 
  • Gefällt mir
Reaktionen: LukS und Colindo
Hat doch noch in den Fingern gekribbelt... Aber testen werde ich heute nichts mehr.
Code:
AMD_DEBUG=info glxinfo | grep vram 
    vram_size = 6144 MB 
    vram_vis_size = 1024 MB 
    vram_type = 9 
    vram_bit_width = 192 
    has_dedicated_vram = 1

Code:
dmesg | grep BAR                   
[    0.223200] pci 0000:0c:00.0: BAR 0: assigned to efifb 
[    5.763022] amdgpu 0000:0c:00.0: BAR 2: releasing [mem 0xffc0000000-0xffcfffffff 64bit pref] 
[    5.763023] amdgpu 0000:0c:00.0: BAR 0: releasing [mem 0xff80000000-0xffbfffffff 64bit pref] 
[    5.763091] [drm:amdgpu_device_resize_fb_bar [amdgpu]] *ERROR* Problem resizing BAR0 (-22). 
[    5.763094] amdgpu 0000:0c:00.0: BAR 0: assigned [mem 0xff80000000-0xffbfffffff 64bit pref] 
[    5.763102] amdgpu 0000:0c:00.0: BAR 2: assigned [mem 0xffc0000000-0xffcfffffff 64bit pref] 
[    5.763120] [drm] Detected VRAM RAM=6128M, BAR=1024M
 
Jesterfox schrieb:
Jein... der abgezweigte RAM wird von der iGPU exklusiv verwaltet, zumindest ohne HUMA. Ist also ähnlich wie der VRAM Und wenn ich mir das von @0x8100 so anschau läuft das über eine emulierte PCIe Verbindung, von daher spielt da wohl das BAR doch mit rein.

Wobei trotzdem die Frage ist was aus HUMA geworden ist... in der PS4 soll das doch schon funktioniert haben, oder?
Ich hab das obige mal auf meinem Laptop mit 4800H ausprobiert und ich bekomme:

Code:
AMD_DEBUG=info glxinfo | grep vram
    vram_size = 2048 MB
    vram_vis_size = 2048 MB
    vram_type = 8
    vram_bit_width = 128
    has_dedicated_vram = 0

Im dmesg steht allerdings nichts zu BAR.

Edit: Stimmt gar nicht. Der Rechner war nur schon zu lange an und der Anfang des logs wurde schon wieder verworfen:

Code:
sudo dmesg | grep BAR
[    0.422771] pci 0000:03:00.0: BAR 0: assigned to efifb
[    1.212456] [drm] Detected VRAM RAM=2048M, BAR=2048M

Edit2: HUMA wurde doch schon mal für APUs und LibreOffice implementiert? Viellicht werden deshalb bei mir auch die BARs direkt richitg mit der VRAM Größe angezeigt und deshalb ist auch kein rBAR bei den APUs nötig?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Leo.16
Es wäre echt schön, wenn Unified Memory für die APUs unter Linux endlich kommt. :/ Windows kann es schon seit ner ganzen Weile für DirectX, aber unter Linux hänge ich bei 512MB VRAM, während die restlichen "15,5"GB vergammeln, weil die Programme nicht mehr adressieren können. (Hier: 4700U)

Regards, Bigfoot29
 
Funktioniert das Ganze eigentlich auch wenn man einen Linux Host hat und darin eine Windows VM mit PCIe passtrough läuft?
Muss man dazu die XML anpassen oder checkt die Hardware von alleine, dass bar Support vorhanden ist?
 
wiwo la vida schrieb:
Funktioniert das Ganze eigentlich auch wenn man einen Linux Host hat und darin eine Windows VM mit PCIe passtrough läuft?
Muss man dazu die XML anpassen oder checkt die Hardware von alleine, dass bar Support vorhanden ist?
Ist zwar nur meine Meinung, aber ich schätze, dass das nicht geht, da man die komplette Kontrolle über das PCIe Gerät an die VM abgibt. der Linux Kernel macht damit vermutlich nichts mehr.
Ergänzung ()

Bigfoot29 schrieb:
Es wäre echt schön, wenn Unified Memory für die APUs unter Linux endlich kommt. :/ Windows kann es schon seit ner ganzen Weile für DirectX, aber unter Linux hänge ich bei 512MB VRAM, während die restlichen "15,5"GB vergammeln, weil die Programme nicht mehr adressieren können. (Hier: 4700U)

Regards, Bigfoot29
Ich glaube, dass die APU schon auf mehr RAM zugreifen kann. die 512MB bei dir bzw. 2048MB bei mir stehen der APU exklusiv zur verfügung: kannst du mal mit glxinfo checken.

Code:
glxinfo -B
...
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 2048 MB
    Total available memory: 5120 MB
    Currently available dedicated video memory: 1690 MB
....
 
Zuletzt bearbeitet:
Hallo

Hier ein kurzer Test von meiner Seite aus unter Ubuntu mit 5.10.4-xanmod1 kernel.
CPU: 3700x
GPU: AMD 5700
MB: B550M Aorus Elite (F11p)
Treiber: Mesa 21.0.0-devel

Irgendwie kann ich das F11p Bios auf der Homepage nicht mehr finden, nur mehr das F10, egal.

Ergebnis in basemark:
4G: on
BAR: auto
Detected VRAM RAM=8176M, BAR=8192M
OpenGL 8133
Vulkan 8238

4G: on
BAR: off
Detected VRAM RAM=8176M, BAR=8192M
OpenGL 8367
Vulkan 8253

4G: off
BAR: off
Detected VRAM RAM=8176M, BAR=256M
OpenGL 8365
Vulkan 7912

Kurz zusammengefasst mit meiner Hardware (also keine 5000er CPU bzw. 6000 GPU), brauche ich nur das 4G Feature zu aktivieren um mehr Leistung zu mindestens unter Vulkan zu bekommen.

Die BAR Option macht für OpenGL nur Probleme und gefühlt fühlen sich auch Vulkan Spiele mit der BAR Option nicht rund an.

Kann sein dass es sich mit aktueller Hardware anderst verhaltet. Meine Empfehlung für dieses Hardware-
Setting ist derzeit einfach nur die 4G Option zu aktivieren, da diese den Leistungsschub zu mindestens unter Vulkan schon erbringt.
 
TarKar schrieb:
Irgendwie kann ich das F11p Bios auf der Homepage nicht mehr finden, nur mehr das F10, egal.
Für mein GigaByte ist das auch so.
 
@Vorgartenzwerg : Ich hab vor ~1 Jahr mal eine große Testreihe mit dem 3400G gemacht und hier (vermutlich im Asrock A300-Thread) gepostet. - Windows vs. Linux mit unterschiedlichem garantiertem "VRAM".

Ergebnis: DirectX (D3D um genau zu sein) arbeitet bis auf die Messtoleranz gleich schnell. Egal, ob da 128MB VRAM oder 4GB vergeben werden. Anders sieht es bei Vulkan und OpenGL aus. Die sind deutlich empfindlicher. Das Gleiche sehe ich jetzt auch wieder bei meinem "kastrierten" 4700U. Unter Windows läuft WoW auf 1440p mit Grafiksetting 5-7. Unter Linux gerademal auf 2-3. Und das bei letzterem auch nur noch bei sehr instabilen FPS. [NACHTRAG] Beim 3400G-Experiment musste das Grafik-Setting nur um eine Stufe zurück, um unter Linux die gleichen, halbwegs stabilen FPS zu liefern.[/NACHTRAG] Gleiches gilt für den Unigine-Benchmark "Superposition". Unter Windows' DirectX habe ich die doppelten Werte, die ich unter Linux erzielen kann. [NACHTRAG] Auf dem 3400G bin ich in der Messtoleranz bei den jeweiligen Läufen. [/NACHTRAG] Das lässt sich auch mit dem 3DMark reproduzieren.

Code:
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 232 MB, largest block: 232 MB
    VBO free aux. memory - total: 3014 MB, largest block: 3014 MB
    Texture free memory - total: 232 MB, largest block: 232 MB
    Texture free aux. memory - total: 3014 MB, largest block: 3014 MB
    Renderbuffer free memory - total: 232 MB, largest block: 232 MB
    Renderbuffer free aux. memory - total: 3014 MB, largest block: 3014 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 512 MB
    Total available memory: 3584 MB
    Currently available dedicated video memory: 232 MB

Die restlichen 3 bzw. 3,5GB sind - wegen fehlendem UMA - deutlich langsamer. Der Prozessor muss die Speicherbereiche jeweils einblenden, was viel Bandbreite kostet.

Daher ist es schon ein wenig ein "rant", wenn AMD vor 10 Jahren UMA so für das HPC hervorhebt und die APUs als Vorzeigeprodukte anpreist und es dann nicht schafft, in/auf dem für HPC wichtigsten OS (H)UMA nicht zum fliegen zu kriegen. Das geht nur für "Daddel-OS". :S

Aber ich gehe weg von RBAR. Von daher... sorry. :D

Regards, Bigfoot29
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Vorgartenzwerg und foo_1337
Vorgartenzwerg schrieb:
Ist zwar nur meine Meinung, aber ich schätze, dass das nicht geht, da man die komplette Kontrolle über das PCIe Gerät an die VM abgibt. der Linux Kernel macht damit vermutlich nichts mehr.
Ich finde hier passt die Begründung nicht zur Antwort.
Wenn die VM exklusiven Zugriff auf das PCIe Gerät hat und man die Cpu auch durchschleift, stellte ich mir schon vor dass es geht.
Aber eine Antwort wird es wohl nur geben, nachdem es jemand probiert hat.
 
Zurück
Oben