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

[0x8100]

@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.

ich meine gelesen zu haben, dass der kernel irgendwo in den pci-registern direkt was umschreibt. mal sehen, ob ich das wieder finde.

edit: siehe z.b. Resizeable PCI BAR support - Patchwork (kernel.org) - die änderungen sind u.a. in drivers/pci/pci.c und es gibt kommentare wie "Many host bridges support programmable windows in the hardware, so in principle we could reprogram them at run-time."

 

[Donnidonis]

Ich bin eher überrascht, dass es bis dato nicht der Standard war, auf den gesamten Speicher zuzugreifen. Aber wenn es dann jetzt kommt soll es ja auch gut sein.

 

[0x8100]

Ich bin eher überrascht, dass es bis dato nicht der Standard war, auf den gesamten Speicher zuzugreifen. Aber wenn es dann jetzt kommt soll es ja auch gut sein.

rein technisch geht das schon lange. aber für den 64bit addressraum brauchst du auch ein 64bit os - und aus kompatibilitätsgründen ist die default-einstellung leider immer noch bei "above-4g-decoding" "off"... genauso wie "csm" im bios deaktiviert sein muss, auch hier ist das meistens immer noch default "on" damit der board-hersteller einen anwendungsfall beim support weniger hat.

 

[LukS]

@Donnidonis
Nein so ist das nicht zu verstehen. Mann konnte auch vorher schon auf den gesamten Speicher zugreifen. Nur halt in nur 256MByte großen Blöcken. Jetzt kann man auf alles auf einmal zugreifen und damit spart man sich in gewissen Fällen etwas Leistung.

 

[foo_1337]

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.

Sicher? Hast du das nur im Kernel Log geprüft oder auch via glxinfo?

 

[0x8100]

Sicher? Hast du das nur im Kernel Log geprüft oder auch via glxinfo?

$ AMD_DEBUG=info glxinfo | grep vram
    vram_size = 8192 MB
    vram_vis_size = 8192 MB
    vram_type = 5
    vram_bit_width = 256
    has_dedicated_vram = 1

$ dmesg | grep BAR
[    0.188094] pci 0000:09:00.0: BAR 0: assigned to efifb
[    3.374852] amdgpu 0000:09:00.0: BAR 2: releasing [mem 0x7ff0000000-0x7ff01fffff 64bit pref]
[    3.374857] amdgpu 0000:09:00.0: BAR 0: releasing [mem 0x7fe0000000-0x7fefffffff 64bit pref]
[    3.374877] pcieport 0000:00:03.1: BAR 15: releasing [mem 0x7fe0000000-0x7ff01fffff 64bit pref]
[    3.374892] pcieport 0000:00:03.1: BAR 15: assigned [mem 0x900000000-0xbffffffff 64bit pref]
[    3.374897] amdgpu 0000:09:00.0: BAR 0: assigned [mem 0xa00000000-0xbffffffff 64bit pref]
[    3.374907] amdgpu 0000:09:00.0: BAR 2: assigned [mem 0x900000000-0x9001fffff 64bit pref]
[    3.374962] [drm] Detected VRAM RAM=8192M, BAR=8192M

edit: jetzt passt der screenshot... es ist ein asrock fatal1ty b450 gaming-itx/ac, da gibt es im bios noch kein sam. das ganze mit einem r7 2700 + rx480.

 

[foo_1337]

@0x8100
Das ist das selbe wie bei Windows. rBAR ist bei dir weder unter Linux noch unter Windows (war ja bereits klar) aktiv. Bei glxinfo fehlt das Entscheidende:
all_vram_visible = 1
Das kommt erst, wenn rBAR im UEFI aktiv ist.

Wobei strange ist, dass vram_vis_size mit 8192 passt. Ohne rBAR sollte die bei 256M liegen.

Edit:

   info->all_vram_visible = info->vram_size * 0.9 < info->vram_vis_size;

Sollte also bei dir auf 1 stehen. Hattest du es nur abgeschnitten?

 

[0x8100]

@foo_1337 k.a. in welcher glxinfo version "all_vram_visible" drin ist. bei mir steht ja kein "all_vram_visible = 0". im dmesg sieht man ja, dass der adressbereich resized wurde und glxinfo sieht auch die vollen 8GB. ohne "above 4g decoding" gibt es auch unter linux nur

    vram_size = 8192 MB
    vram_vis_size = 256 MB

edit: das ist erst vor 3 wochen reingekommen. ich hab stable mesa drauf, daher habe ich das noch nicht.

 

[foo_1337]

Kam hier dazu: https://gitlab.freedesktop.org/mesa/mesa/-/commit/d3d6d38145047a9d531be0e4aba71ab788259b41
Dann liegt es tatsächlich nur an der älteren Mesa Version. Sorry für die Verwirrung, ich hatte zuerst nicht auf vram_vis_size geschaut, da ich schon die aktuelle Mesa Version habe. Ich probiere das mal morgen auf der Kiste aus ohne explizit aktiviertes rBAR im Bios.

 

[0x8100]

das ist der code für "all_vram_visible"

info->all_vram_visible = info->vram_size * 0.9 < info->vram_vis_size;

dementsprechend wird bei mir auch "1" stehen

 

[Jesterfox]

Hm... mal so ne Frage zu den APUs: die hängen doch gar nicht am PCIe, von daher kann da das BAR doch gar keine Rolle spielen? Für die ist doch eher HSA/HUMA interessant, dass sie direkt den RAM der CPU teilen und nicht getrennte Bereiche die umkopiert werden müssen, oder?

 

[0x8100]

für das betriebssystem ist das ein ganz normales pci-e device (so wie die anderen integrierten sachen in der apu, siehe alles unter 08.1):

$ lspci -tv
-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex
           +-00.2  Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
           +-01.0  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge
           +-01.2-[01-08]--+-00.0  Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller
           |               +-00.1  Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller
           |               \-00.2-[02-08]--+-00.0-[03]--
           |                               +-01.0-[04]--
           |                               +-04.0-[05]--
           |                               +-05.0-[06]--
           |                               +-06.0-[07]----00.0  Intel Corporation Device 2723
           |                               \-07.0-[08]----00.0  Intel Corporation I211 Gigabit Network Connection
           +-01.6-[09]----00.0  Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
           +-08.0  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge
           +-08.1-[0a]--+-00.0  Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series]
           |            +-00.1  Advanced Micro Devices, Inc. [AMD/ATI] Raven/Raven2/Fenghuang HDMI/DP Audio Controller
           |            +-00.2  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
           |            +-00.3  Advanced Micro Devices, Inc. [AMD] Raven USB 3.1
           |            +-00.4  Advanced Micro Devices, Inc. [AMD] Raven USB 3.1
           |            \-00.6  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
           +-14.0  Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller

 

[Colindo]

Hm... mal so ne Frage zu den APUs: die hängen doch gar nicht am PCIe, von daher kann da das BAR doch gar keine Rolle spielen?

Habe ich mir auch gedacht. Keine Ahnung, wie das zusammen passen soll. Es gibt jedenfalls keinen VRAM, auf den man zugreifen könnte. Im Gegenteil müssten die Vorteile direkt zur Verfügung stehen, oder nicht?

 

[foo_1337]

@Colindo jo, ich muss da auch direkt an UMA bzw AMD's hUMA denken.

 

[Jesterfox]

Es gibt jedenfalls keinen VRAM, auf den man zugreifen könnte.

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?

 

[C4rp3di3m]

Resizable BAR für alle​

Da AMD Smart Access Memory auf dem offenen Standard Resizable BAR basiert, der seinerseits Bestandteil von PCIe 3.0 ist und auf das Jahr 2008 zurückgeht, sind alle halbwegs aktuellen CPUs und GPUs in der Lage das Feature zu nutzen – ein entsprechendes BIOS und der passende Treiber-Support vorausgesetzt.

Exakt und ich freue mich Natürlich sehr das es bei mir problemlos Funktioniert unter windows

mfg

 

[longusnickus]

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).

gibt doch jetzt schon ein paar spiele, die auf linux schneller laufen. ich glaube CSGO (das läuft glaube ich noch auf dx9 und das ist opengl anscheinend unterlegen) und bethestda spiele mit vulkan und ich glaube Detroit: Become Human

Bei solchen News denke ich mir immer .. ganz nett aber im Grunde uninteressant, solange keine Grafikkarten verfügbar sind. Diese Situation ist echt ein Armutszeugnis.

nachdem nvidia das nachträglich erst "einbaut" sollten es eigentlich auch ältere karten können. möglich, dass man dafür das grafikkarten bios updaten müsste

 

[Matthias80]

Da muss echt mal ne Lanze für AMD gebrochen werden!
Am Beispiel SAM sieht man sehr schön, die denke von AMD!
Wie, wo können wir unseren Kunden mehr Leistung verschaffen? Muss das was koste? Ne! Oh schau mal hier ein uraltes Limit. Wenn wir das... Oh cool! Zack ist es da.

NVIDIA dagegen... Was können wir machen um noch mehr Kohle rauszuquetschen? Nen allgemeinen Standard unterstützen damit sich die Technik schneller verbreitet? Neee! Bringt Ja keine Kohle. Wir machen was eigenes! Erstmal Version 1.0. Zeigt gleich das wird schon noch besser. Ah teurer.
Zack RT, gsync ect. Ect. Ect.

Glaub AMD ist auf dem richtigen Weg. NV wird deine Linux Treiber bald wohl nur gegen Geld anbieten...? Verdammt jetzt hab ich die wohl auf Ideen gebracht.

Mfg

 

[foo_1337]

Was genau war/ist an RT proprietär? Die (erste) Vulkan Extension, bei der auch AMD und Intel beteiligt waren? Die Zusammenarbeit für Microsoft an DXR, was auch AMD und Intel zugute kommt?

Und die Treiber hast du bereits mit dem Kauf der Karte bezahlt. Schon immer.

 

[Jesterfox]

Was genau war/ist an RT proprietär?

RT an sich ist es nicht, richtig. Das Toolset das NV liefert aber schon. Und man hat ja auch an der Verwendung von Tesselation (eigentlich ein feature von AMD) gesehen wie NV Toolsets agieren...

GSync dagegen ist proprietär, während AMD mit VESA an einem offenen Standard zusammengearbeitet hat (adaptive Sync)