AMD Lands More Graphics Updates For Linux 6.8: More MI300 & RDNA3 Refresh Work

[phoronix]

Phoronix: AMD Lands More Graphics Updates For Linux 6.8: More MI300 & RDNA3 Refresh Work

Following last week's initial set of AMDGPU kernel graphics driver changes for Linux 6.8, another weekly pull request was submitted on Friday to DRM-Next of further changes...

https://www.phoronix.com/news/More-AMDGPU-Linux-6.8

[Kjell]

Seems like SR-IOV updates are a reoccurring theme in AMDGPU.

Is it reasonable to assume all this work around SR-IOV is for virtualization of future consumer grade GPUs?

AMD could easily win over a lot of NVIDIA's customers with such feature. Especially homelab enthusiasts (which from my experience causes a domino effect and translates to professional/business usage).

[illwieckz]

- SR-IOV fixes

Which GPU?

[muncrief]

I've been buying AMD only systems so long that I can't remember, even before and during the disastrous Bulldozer fiasco.

And I always will, as I will never succumb to Intel which destroyed so many lives and companies during their draconian drive for dominance during the 70s to 90s, not to mention their schemes to keep CPU prices outrageously high until AMD finally came along to compete with them. And Nvidia is simply an Intel light, who would drive the cost of GPUs into the stratosphere if competition from AMD didn't exist.

But my goodness AMD, this is yet another plea from one of the millions of us who supported you through good times and bad - please finally develop a Linux GUI for your GPUs. There have been numerous attempts by open source developers to develop AMD GPU GUIs but they all fail miserably, so unfortunately there just isn't anything that comes even close to the Adrenalin GUI in Windows.

I understand that by now it will be a miracle if it ever happens, but I thought I'd throw yet another message in a bottle into the sea, with the hope that one day someone from AMD will open and read it, and understand that they lose many Linux GPU customers simply because there is no GUI to control them.

It really is a no brainer decision, but for some reason this is one place where AMD not only falls short, but continually jumps off a cliff.

With a smile on its face all the way down to the rocks.

[superm1]

But my goodness AMD, this is yet another plea from one of the millions of us who supported you through good times and bad - please finally develop a Linux GUI for your GPUs. There have been numerous attempts by open source developers to develop AMD GPU GUIs but they all fail miserably, so unfortunately there just isn't anything that comes even close to the Adrenalin GUI in Windows.

I understand that by now it will be a miracle if it ever happens, but I thought I'd throw yet another message in a bottle into the sea, with the hope that one day someone from AMD will open and read it, and understand that they lose many Linux GPU customers simply because there is no GUI to control them.

It really is a no brainer decision, but for some reason this is one place where AMD not only falls short, but continually jumps off a cliff.

With a smile on its face all the way down to the rocks.

amdgpu does the best it can to be a "good open source citizen". This means that it exports hardware information via hwmon, and fits applicable changeable items into DRM properties. Things that don't make sense as DRM properties are sysfs files. The side effect of all this is what a graphical application can do are very limited from the security boundaries. DRM properties can only be changed by the compositor. Let me give you an example. There is a feature offered in Radeon Sofware for Windows called "Varibright". This is supported in Linux as "ABM" and exports a DRM property as such:

$ drm_info | grep abm
│ │ ├───"abm level": range [0, 4] = 3
​

Even if AMD had made a GUI tool it can't manipulate this option, only the compositors like mutter, sway or kwin could. Similar limitations exist for other DRM properties.

Making a GUI that wraps the sysfs files is relatively doable but changing them will require root permissions. So that means you either would need to run the GUI as root or have a helper daemon that works with the GUI to change options. This is actually what LACT does.

In my mind the right way forward is that all the compositors need to be willing to add graphical toggles for vendor specific DRM properties and amdgpu can export everything relevant to be changed through those in addition to sysfs files.

[muncrief]

amdgpu does the best it can to be a "good open source citizen".
...
Even if AMD had made a GUI tool it can't manipulate this option, only the compositors like mutter, sway or kwin could. Similar limitations exist for other DRM properties.

Making a GUI that wraps the sysfs files is relatively doable but changing them will require root permissions. So that means you either would need to run the GUI as root or have a helper daemon that works with the GUI to change options. This is actually what LACT does.

In my mind the right way forward is that all the compositors need to be willing to add graphical toggles for vendor specific DRM properties and amdgpu can export everything relevant to be changed through those in addition to sysfs files.

AMD is perfectly capable of producing a fully functional GPU GUI, just as Intel and Nvidia do. In fact AMD is even better positioned than their competitors, as they are indeed dedicated to open source and have intricate connections with other Linux developers, including kernel developers.

And my goodness, I don't believe that continuing to break down Linux with all these compositor wars, that require completely different code for what used to be generic system functions, is the correct approach at all. In fact I believe it to be a further fragmenting and damaging one.

Whatever current impediments exist within the kernel can easily be washed away with a dedicated desire by AMD and other developers to do so.

The simple truth is that AMD just doesn't want to put in the effort. And if their loyal customers don't continue to push them to do so AMD will never have a functional Linux GUI, and their Linux sales will continue to suffer because of their intransigence.

[superm1]

AMD is perfectly capable of producing a fully functional GPU GUI, just as Intel and Nvidia do. In fact AMD is even better positioned than their competitors, as they are indeed dedicated to open source and have intricate connections with other Linux developers, including kernel developers.

Wait, Intel offers a GUI for Linux?

This is my opinion; but I feel the reason for an official GUI tool is when you offer proprietary methods to change settings. Going back to my Varibright example above in the Windows ecosystem there isn't the ability for AMD to expose something in the "normal" Windows display settings panel for this AMD specific feature. So the only way to expose it to people is an AMD proprietary tool.

NVIDIA (AFAIK) doesn't offer DRM properties or sysfs for any of their settings. The only way you can change them is their proprietary driver interface.

And my goodness, I don't believe that continuing to break down Linux with all these compositor wars, that require completely different code for what used to be generic system functions, is the correct approach at all. In fact I believe it to be a further fragmenting and damaging one.

Whatever current impediments exist within the kernel can easily be washed away with a dedicated desire by AMD and other developers to do so.

The expectation from the DRM API is that only the DRM master can use these IOCTLs that will change settings. This is fundamental to the API and I don't see any way it can be changed. So in the typical Linux Wayland desktop this is the role the compositor plays. This is for example why on a GNOME desktop you can only change panel resolutions in GNOME Control Center.

The simple truth is that AMD just doesn't want to put in the effort. And if their loyal customers don't continue to push them to do so AMD will never have a functional Linux GUI, and their Linux sales will continue to suffer because of their intransigence.

I think it would be really constructive to understand what you want to see in a proposed GUI tool and how you would want to use it.

I'd personally love to see a section in both GNOME and KDE display settings panels for any of the AMD specific settings that are exported as DRM properties. If we can make a case for one setting to show up and let the compositor control it we can work on growing it for others.

[theriddick]

It's a open source driver, there are open source GUI tools for AMD. Some are old, and couple I think are new or still updated.
Its just not something you include in a kernel.
AMD should give a crack at it sure, or Valve.

[smitty3268]

But my goodness AMD, this is yet another plea from one of the millions of us who supported you through good times and bad - please finally develop a Linux GUI for your GPUs. There have been numerous attempts by open source developers to develop AMD GPU GUIs but they all fail miserably, so unfortunately there just isn't anything that comes even close to the Adrenalin GUI in Windows.

Can you explain what CoreCtrl and LACT are failing at, in your opinion, that you'd like to see from an AMD GUI?

Is this a request for some of the windows-only driver features with fancy marketing names that AMD hasn't ported to linux?

[chithanh]

Is it reasonable to assume all this work around SR-IOV is for virtualization of future consumer grade GPUs?

AMD could easily win over a lot of NVIDIA's customers with such feature. Especially homelab enthusiasts (which from my experience causes a domino effect and translates to professional/business usage).

I agree that the limited mindshare among homelabs is hurting industry-wide AMD adoption big time. But AMD predominantly doesn't see it that way. Homelabs are always least concern for them, last time with the Epyc/Ryzen Pro PRSB vendor lock which inhibits the market for secondhand CPUs.

AMD is still governed by corporate beancounters, and because homelabs do not directly translate into new unit sales and you cannot put an $ value on community mindshare or community technology adoption, AMD continues to stand in their own way.