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

[Fouquin]

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.



View at TechPowerUp Main Site | Source

 

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

 

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

 

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

 

[s3thra]

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.

PlayStation uses FreeBSD, not Linux. Similar but not the same thing.

 

[Ferrum Master]

PlayStation uses FreeBSD, not Linux. Similar but not the same thing.

For PS4 for sure... But I have no hard info about PS5 OS.

 

[nienorgt]

Engineer: hey boss, theres a bug in our open source driver
Boss: Don't bother fixing it just disable the feature

 

[Mussels]

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.

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

 

[librin.so.1]

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.

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:

SAM 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