A Linux Fix Is On The Way For Some GPUs Having AMD Smart Access Memory Issue

[phoronix]

Phoronix: A Linux Fix Is On The Way For Some GPUs Having AMD Smart Access Memory Issue

A Linux fix is on the way for a new quirk to address an issue whereby some AMD Radeon graphics cards have an issue with the resizable BAR (AMD Smart Access Memory) handling that could lead to lower performance...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Quirk-SAM-GPU-Quirk

[doomie]

oh cool, so my sapphire 5700 may benefit eventually after all

[CochainComplex]

I'm also waiting for a patch 5700XT

[ms178]

I wonder how this issue happened in the VBIOS of that vendor, I would naively assume that all vendors more or less use the reference VBIOS from AMD and tweak some settings for their specific card, but nothing that would touch this feature.

[CochainComplex]

I wonder how this issue happened in the VBIOS of that vendor, I would naively assume that all vendors more or less use the reference VBIOS from AMD and tweak some settings for their specific card, but nothing that would touch this feature.

Most likely yes. Maybe they have some tool to set different parameters max boost clock etc. But under the hood it is the same vbios generator ? Just my guess too.

If you look at the VBIOS Database of Techpowerup you will see that there is not much of changes in Biosversion for one type of card of one OEM. Maybe in the production lifetime of one card you will see 1 up 3 different revisions of the bios- I would say the median value might be around 1,5. Besides the Bios Versioning seems to look similar even if you look at the overview with multiple vendors and the BIOS have some autodetect features for DDR recognition.

That let me think that they get a "reference bios" + reference pcb layout from AMD. Then they check and tune if it works with their design implementation ..but not like AGESA there might be mostly not much updates after the initial stable ref bios.

Otherwise BIOS editors would not work so seamless on different vendor cards and models.

This is my theory too but I have no proof - take it with some grain of salt.


p.s.: I remember barely that I used two bioses - one with uefi, one without and I tinkered a new uefi bios on a original non uefi card. Don't ask the details some time ago cant really remember. But it was basically two bioses of one vendor but different card models ..more or less hex copy and paste as far as I remember - rather generic structure.

[ms178]

By the way, according to Marek, we need to learn one more environment variable on systems which are not Zen3/RDNA2 for SAM: https://gitlab.freedesktop.org/mesa/...51#note_750262

I did argue for a opt-out solution for later Mesa releases to make life a bit easier by default. But it seems he wants to stick with the more restrictive opt-in approach.

I hope the developers would think more of the average user experience, all the things one has to know for configuring their PCs add up complexity over time, just thinking of all the things I need to setup for a perfect config: Performance governor (hence a custom Kernel), Freesync in xorg.conf.d, mitigations=off on the command line and now also this.... (I am sure I have missed something important, too).

[agd5f]

By the way, according to Marek, we need to learn one more environment variable on systems which are not Zen3/RDNA2 for SAM: https://gitlab.freedesktop.org/mesa/...51#note_750262

I did argue for a opt-out solution for later Mesa releases to make life a bit easier by default. But it seems he wants to stick with the more restrictive opt-in approach.

I hope the developers would think more of the average user experience, all the things one has to know for configuring their PCs add up complexity over time, just thinking of all the things I need to setup for a perfect config: Performance governor (hence a custom Kernel), Freesync in xorg.conf.d, mitigations=off on the command line and now also this.... (I am sure I have missed something important, too).

The idea is to provide the best customer experience out of the box. Most things users "configure" are already defaults or are not necessary, or are not the default for a reason. Updating the sbios is not something that a lot of users end up doing for better or worse.

[ms178]

The idea is to provide the best customer experience out of the box.

That's exactly why I argued with Marek over the best default setting. I've written down my reasoning on Gitlab and while I don't have a problem with his decision for the next couple of months, some people who reported performance problems before on AM4 said that a BIOS update fixed their issues (documented here, here and here). When the dust has settled and more testing has been done on other platforms in a couple of months, I hope it becomes safe enough to broaden the default again. Unfortunately these things tend to be set once and forgotten about later on, so I just want to make sure it is not (and am happy to open a tracker bug about it). Also with this series I assume a newer VBIOS for the 5600XT is no longer needed, so one less problem to worry about.

Most things users "configure" are already defaults or are not necessary, or are not the default for a reason.

That is a way too generic statement for me which doesn't reflect my own findings over the last couple of years learning Linux. One specific example, what is the reason for not getting Freesync enabled with Xorg by default? I still need to create a file in /etc/X11/xorg.conf.d/ named 10-amdgpu.conf with the following content:

Section "OutputClass" Identifier "AMDgpu" MatchDriver "amdgpu" Driver "amdgpu" Option "DRI" "3" Option "VariableRefresh" "true" EndSection

My point: All these little things add up complexity over time which is too much to keep in mind for an average Windows user giving Linux a try and expect to get these features working out of the box. Not everyone is keen on digging through the documentation to find all the answers.