Smart access memory linux

AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement

Following Mesa 21.0 beginning to see AMD Smart Access Memory optimizations, I ran some benchmarks looking at the current state of S.A.M. / Resizable BAR support on Linux with Radeon graphics.

As has been outlined previously, the Linux kernel has actually supported resizable BAR for a while (or Smart Access Memory as referred to by AMD) while on the user-space driver side just this past week with Mesa 21.0 did we begin seeing the mentioned RadeonSI improvements. Details on verifying if Resizable BAR support is enabled on Linux can be found via this forum thread.

This week there’s also been some separate Linux AMDGPU patches to improve BAR resizing but not yet found in any released kernel nor queued for 5.11. «This patch series improves the existing BAR resizing support in amdgpu. By default, it will attempt to resize BAR0 for each dGPU present to cover the VRAM, falling back to smaller sizes if necessary, e.g. if there’s not enough address space remaining or support for the size is not advertised. Basic boot-time (or module load time) options to control this resizing are implemented: one to control whether resizing is done (and whether the advertised BAR sizes are ignored) and one to control the maximum BAR size (where the size would be increased). At present, these are coarse; they apply to all dGPUs driven by amdgpu.»

With Mesa 21.0 after the RadeonSI patches landed and when using Linux 5.10-rc6 on the kernel side, I ran some quick benchmarks looking at the resizable BAR support on Linux with various OpenGL and Vulkan games. This was with the Ryzen 9 5950X running on the ASUS ROG CROSSHAIR VIII HERO WiFi motherboard where with the latest BIOS update makes it very prominent to toggle resizable BAR support.

For many OpenGL/Vulkan games on the few AMD Radeon graphics cards tested there was barely any performance difference at this time, but some uplift for a few Linux games:

Will be around with more benchmarks once the AMD Smart Access Memory support settles down with any further optimizations to come. If you have been trying it out on Linux, be sure to comment on this article in the forums with your experiences as it appears the AMD open-source developers are still looking for more testing/feedback.

Источник

Mesa 21.0 Begins Landing Optimizations For AMD Smart Access Memory

While AMD Smart Access Memory has already been supported under Linux for some time with its resizable BAR functionality, only now with all the excitement around the feature being promoted with the Ryzen 5000 series and Radeon RX 6000 series hardware is the Mesa driver code beginning to see some optimizations for it.

Lead RadeonSI developer Marek Olšák of AMD has merged a set of optimizations for AMD Smart Access Memory that will come in next quarter’s Mesa 21.0 release. The code that landed today include a helper for determining Smart Access Memory / all vRAM visible, only force the staging uploads for vRAM when Smart Access Memory isn’t enabled, and only use staging for linear textures when the feature is disabled. For cases when Smart Access Memory is enabled, vRAM is now used for command buffers, the pipe usage stream is mapped to vRAM, and the uploading code has been unified and going straight to vRAM with this feature enabled. More details within this merge request.

These Smart Access Memory optimizations are focused on the RadeonSI Gallium3D code. The code is queued in Mesa 21.0-devel while the stable release with this functionality should be out in March, hopefully before then we’ll see more optimizations.

For those wondering how to check if Smart Access Memory is enabled for your Linux system, see the details in this forum thread.

I was in the process already of running some AMD Smart Access Memory Linux benchmarks while I’ll be restarting them now with this latest Mesa Git.

Источник

AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement

AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement

Phoronix: AMD Smart Access Memory / Resizable BAR On Linux Still Ripe For Improvement

Following Mesa 21.0 beginning to see AMD Smart Access Memory optimizations, I ran some benchmarks looking at the current state of S.A.M. / Resizable BAR support on Linux with Radeon graphics.

Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

Apparently, if you have «above 4g decoding» enabled in bios, that means you have resizable BAR support on Linux/AMDGPU. At least with ASUS, not all boards have this BIOS setting. I know that all or most ROG boards have this setting and some Prime boards have it as well, but my board (Prime Z390-P) doesn’t have it.

Comment

So, of course AMD lied about «smart access memory» being supported only on the latest generation CPUs and GPUs. Greedy AMD artificially tries to motivate people to buy the latest stuff, by restricting the Windows support.

On Linux we are now adding support and optimizations that are applied regardless of the hardware generation. Older hardware gets a nice performance benefit, too!

Comment

On Linux we are now adding support and optimizations that are applied regardless of the hardware generation.

Comment

So, of course AMD lied about «smart access memory» being supported only on the latest generation CPUs and GPUs. Greedy AMD artificially tries to motivate people to buy the latest stuff, by restricting the Windows support.

On Linux we are now adding support and optimizations that are applied regardless of the hardware generation. Older hardware gets a nice performance benefit, too!

AMD did not lie, they only promised Windows support for that combination. Also, «we» ? You don’t sound like a Open Source developer, any patch of yours recently?

Comment

Apparently, if you have «above 4g decoding» enabled in bios, that means you have resizable BAR support on Linux/AMDGPU. At least with ASUS, not all boards have this BIOS setting. I know that all or most ROG boards have this setting and some Prime boards have it as well, but my board (Prime Z390-P) doesn’t have it.

Comment

So, of course AMD lied about «smart access memory» being supported only on the latest generation CPUs and GPUs. Greedy AMD artificially tries to motivate people to buy the latest stuff, by restricting the Windows support.

On Linux we are now adding support and optimizations that are applied regardless of the hardware generation. Older hardware gets a nice performance benefit, too!

I’ve asked an AMD developer on the day they announced it here on Phoronix, and he told us an honest answer also that Windows has stricter requirements. You can’t blame them for validating that feature on their own hardware and market it that way. I would have chosen a different message and we also might get it enabled on more platforms later on. I’ve already seen a Vega user who had a 400-series board with the latest BIOS and got a new driver entry with large address space in the device manager. I personally would like to see Windows support on Intel platforms as old as X99 which should be capable to support this, but validation takes some time.

Comment

Come on guys, seriously? Why the hostility? I said «we» as in the Linux community. We all (Linux users and devs) are getting a nice perf improvement thanks to the Linux drivers not discriminating about hardware support. That «we» never implied me personally taking credit for that specific work. Those drivers, being open-source, are the work of the community (which AMD is a part of, and the biggest contributor to their own drivers), and «we» all get to enjoy it.

Also, yes, BTW, I am an open-source developer. I don’t work on the kernel and drivers, though. I contribute to the Bevy rust game engine the related open-source game dev ecosystem.

(as well as working on my own game, but that ain’t open-source)

Comment

I’ve asked an AMD developer on the day they announced it here on Phoronix, and he told us an honest answer also that Windows has stricter requirements. You can’t blame them for validating that feature on their own hardware and market it that way. I would have chosen a different message and we also might get it enabled on more platforms later on. I’ve already seen a Vega user who had a 400-series board with the latest BIOS and got a new driver entry with large address space in the device manager. I personally would like to see Windows support on Intel platforms as old as X99 which should be capable to support this, but validation takes some time.

My point was that in their public announcement to the masses, they made it sound like it was some magical synergy between their latest generation of CPUs and GPUs. That was then quickly debunked, with people showing that it is a standard PCIe feature (which was not really utilized until now) and NV/intel also saying that they will support it.

Of course, the technicalities are more subtle. Linux had support for these PCIe features for a long time. And I don’t doubt that technical restrictions on Windows made it difficult.

My point was that the initial mass marketing coming officially from AMD was misleading.And it led to the early announcement-day/launch-day media coverage amplifying that message.

Источник