Thursday, March 9th 2023

SAM/ReBAR Stripped Out of AMD Open-Source OpenGL Driver RadeonSI Gallium3D

Support for AMD's Smart Access Memory and the overarching Resizable BAR technologies has been removed from the RadeonSI Gallium3D OpenGL driver as of today's Mesa 22.3.7 release. The comment in the announcement simply reads, "Disable Smart Access Memory because CPU access has large overhead." The nail in the coffin seems to have been this bug ticket submitted last month for the game Hyperdimension Neptunia Re;Birth1, in which the user reported the game running oddly slow on their RX 6600 while previously they had no issues on the much older R9 380. The solution provided was to simply disable ReBAR/SAM either with radeonsi_disable_sam=true or via UEFI. In the comments of the ticket lead RadeonSI developer Marek Olšák states, "We've never tested SAM with radeonsi, and it's not necessary there."

Apparently the performance advantages weren't panning out for RadeonSI, and since direct optimizations of these features was not a primary goal the decision was made to cut them out. Attempts to optimize SAM with RadeonSI date as far back as December 2020 and Mesa 21.0, but support for SAM under Linux goes further back. None of the changes to RadeonSI will affect other drivers such as RADV, the open-source Radeon Vulkan driver, and this code change is limited to only the RadeonSI OpenGL driver.
Source: Phoronix
Add your own comment

8 Comments on SAM/ReBAR Stripped Out of AMD Open-Source OpenGL Driver RadeonSI Gallium3D

#1
ADB1979
I am no expert here, but don't companies typically say such things because they are about to fix this and see the storm brewing." and thus get ahead of it, and put their driver team to the face of the wheel...
Posted on Reply
#2
NC37
And just recently there was reviews showing how beneficial this was, especially for the new 7900s on AMD hardware. Also showed how the tech only really benefits AMD on AMD or nVidia on Intel. Even turned it on with my XT and saw improvements.
Posted on Reply
#3
Ferrum Master
The weird thing that SAM is part of PCIe spec and not something AMD came with, basically Linux was aware of it way before GPU's started using it. The problem is handled in a weird matter also.

The most important question lies... as the biggest Linux user SONY, how do they handle it. I bet they have it working fine... there is something else going on.
Posted on Reply
#4
s3thra
Ferrum MasterThe weird thing that SAM is part of PCIe spec and not something AMD came with, basically Linux was aware of it way before GPU's started using it. The problem is handled in a weird matter also.

The most important question lies... as the biggest Linux user SONY, how do they handle it. I bet they have it working fine... there is something else going on.
PlayStation uses FreeBSD, not Linux. Similar but not the same thing.
Posted on Reply
#5
Ferrum Master
s3thraPlayStation uses FreeBSD, not Linux. Similar but not the same thing.
For PS4 for sure... But I have no hard info about PS5 OS.
Posted on Reply
#6
nienorgt
Engineer: hey boss, theres a bug in our open source driver
Boss: Don't bother fixing it just disable the feature
Posted on Reply
#7
Mussels
Freshwater Moderator
NC37And just recently there was reviews showing how beneficial this was, especially for the new 7900s on AMD hardware. Also showed how the tech only really benefits AMD on AMD or nVidia on Intel. Even turned it on with my XT and saw improvements.
That has nothing to do with this news or its content



It's an open source openGL driver, nothing to do with any other OS platform or rendering method
Posted on Reply
#8
librin.so.1
Ferrum MasterThe weird thing that SAM is part of PCIe spec and not something AMD came with, basically Linux was aware of it way before GPU's started using it. The problem is handled in a weird matter also.

The most important question lies... as the biggest Linux user SONY, how do they handle it. I bet they have it working fine... there is something else going on.
The article is misleading: they didn't remove ReBAR support, it's still fully there. What was removed were specifically certain memory placement optimizations that are possible to do when ReBAR is active (that's where the "smart" in SAM comes from).

See:
Marek OlšakSAM isn't really removed. The behavior that's removed is an aggressive use of VRAM for everything when SAM is enabled in the BIOS, which has slower CPU access.
SAM is still used if an app specifically asks for VRAM and then demands full CPU access to it. The kernel handles that optimally if SAM is enabled in the BIOS.
further clarifications Here and Here
Posted on Reply
May 21st, 2024 07:58 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts