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

[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. Level1Techs and others have been campaigning for years to get at least some limited SR-IOV support to consumer GPUs. 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, and before that by simply not making their drivers for enterprise products public.

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

[zboszor]

Making a GUI that wraps the sysfs files is relatively doable but changing them will require root permissions.

This is not just relatively doable, but completely doable. This is what Polkit is about. https://en.wikipedia.org/wiki/Polkit

Some examples:

You can do firewall changes and user management through GUI using Polkit, which all need root privileges.

libfprint (the low level fingerprint user space driver set) would need root privileges. Instead, there's fprintd which runs as root and provides a DBus service which in turn requires a Polkit descriptor file for your application that allows talking it to talk to fprintd.

[hartree]

I don't really miss a GUI per se, but it could be a way to increase usability by showing which different drivers, environment variables, packages like ROCM and generally tweakable settings are already available.
Right now it takes new users a lot of effort to grok all that information, and many are left thinking some things that are available simply aren't.

It's understandable that this isn't as much of a priority as the very polished Windows interface, but there could be a compromise.
An "Radeon on Linux" web page/wiki that is kept up-to-date and lists all important information, tells users which cards support which features with what kernels and packages, and even points them to community software like the overclocking GUIs or explains the distinction between the different drivers and why they exist would go a long way since these questions even pop up on here among very well informed enthusiasts.

[Panix]

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.

GUI? No, this is the AMD attitude - "we already 'open-sourced' our hardware - you can get the community to do the software stuff. Get lost."

[bridgman]

GUI? No, this is the AMD attitude - "we already 'open-sourced' our hardware - you can get the community to do the software stuff. Get lost."

Not any AMD'er I know. At worst it would be "what should we not do so we have time to work on a GUI ?".

You can't say OGL-P or RADV because those are other parts of the SW org (ie not our people) and you can't say packaged drivers because we rely on them for ROCm as well. If you think there are other things we are doing today that are lower priority than a GUI then we're open to suggestions.

[Panix]

Not any AMD'er I know. At worst it would be "what should we not do so we have time to work on a GUI ?".

You can't say OGL-P or RADV because those are other parts of the SW org (ie not our people) and you can't say packaged drivers because we rely on them for ROCm as well. If you think there are other things we are doing today that are lower priority than a GUI then we're open to suggestions.

Well, I think the guy I quoted was talking about open source developers creating some GUIs - his conclusion is just that they all 'suck' (?) or are unsatisfactory for some reason? But, AMD has not offered any - so this huge gazillion dollar company can't even do what these other smaller companies have done? Offer something? How much time does AMD need?

https://www.reddit.com/r/linux/comments/a5q366/linux_amd_card_power_controlfan_control/

https://steamcommunity.com/app/221410/discussions/0/1777136225015918222/?l=polish&ctp=3

https://www.reddit.com/r/linux_gaming/comments/12wiit0/why_is_overclocking_power_voltage_and_fan_control/

https://www.phoronix.com/news/WattmanGTK-Linux-AMDGPU

I only hear crickets.

[agd5f]

Well, I think the guy I quoted was talking about open source developers creating some GUIs - his conclusion is just that they all 'suck' (?) or are unsatisfactory for some reason? But, AMD has not offered any - so this huge gazillion dollar company can't even do what these other smaller companies have done? Offer something? How much time does AMD need?

https://www.reddit.com/r/linux/comments/a5q366/linux_amd_card_power_controlfan_control/

https://steamcommunity.com/app/221410/discussions/0/1777136225015918222/?l=polish&ctp=3

https://www.reddit.com/r/linux_gaming/comments/12wiit0/why_is_overclocking_power_voltage_and_fan_control/

https://www.phoronix.com/news/WattmanGTK-Linux-AMDGPU

I only hear crickets.

I don't know about crickets. Every time this comes up, someone from AMD tries to address it.

Let me flip that around, what are these tools missing that an AMD developed tool would add? Not to mention, the problems several people have brought up before, with wayland based compositors, only the compositor has access to the display KMS interfaces, so we would need to work with every compositor out there to integrate a GUI for display handling. It's not really clear what that would add over an above the standard display GUIs provided by the compositors themselves. To actually make use of a lot of the useful hardware features (display overlays and underlays, post processing of application buffers for things like frame insertion or scaling, etc.), you really need to make make major changes to the compositor itself. I guess we could also add a bunch of AMD branding. At that point you basically have to maintain your own compositor. Beyond that, it's basically just a overclocking tool of which there are many already. On top of that, there are kernel rules that you can't add vendor specific display extensions which harkens back to the original problem which is that every compositor that would want to use those extensions would need to add support. The idea is that we can only add a new vendor agnostic extension if you get buy in from both a GPU driver and a compositor, even then, for major new features, you need to build broad industry support. Look at HDR. Even beyond that you get into the philosophical area. If we write it in GTK, someone will complain. If we write it in Qt, someone will complain. If we target KDE or GNOME, someone will complain. Then, as bridgman mentioned, there is the effort. Note that desktop Linux is a really small market. So, yeah, AMD may be a large company, but it's a business, the teams are sized to to deliver the features dictated by the market size. Resources are put on projects that deliver the most revenue for the company.

[Panix]

I don't know about crickets. Every time this comes up, someone from AMD tries to address it.

Let me flip that around, what are these tools missing that an AMD developed tool would add? Not to mention, the problems several people have brought up before, with wayland based compositors, only the compositor has access to the display KMS interfaces, so we would need to work with every compositor out there to integrate a GUI for display handling. It's not really clear what that would add over an above the standard display GUIs provided by the compositors themselves. To actually make use of a lot of the useful hardware features (display overlays and underlays, post processing of application buffers for things like frame insertion or scaling, etc.), you really need to make make major changes to the compositor itself. I guess we could also add a bunch of AMD branding. At that point you basically have to maintain your own compositor. Beyond that, it's basically just a overclocking tool of which there are many already. On top of that, there are kernel rules that you can't add vendor specific display extensions which harkens back to the original problem which is that every compositor that would want to use those extensions would need to add support. The idea is that we can only add a new vendor agnostic extension if you get buy in from both a GPU driver and a compositor, even then, for major new features, you need to build broad industry support. Look at HDR. Even beyond that you get into the philosophical area. If we write it in GTK, someone will complain. If we write it in Qt, someone will complain. If we target KDE or GNOME, someone will complain. Then, as bridgman mentioned, there is the effort. Note that desktop Linux is a really small market. So, yeah, AMD may be a large company, but it's a business, the teams are sized to to deliver the features dictated by the market size. Resources are put on projects that deliver the most revenue for the company.

I'm not an expert in this area, obviously - I was just responding to the other guy who claims they 'all suck' - the alternative open source projects which aim to do the same thing as Adrenalin does in Windows. Personally, I think it was a rather unfair critique and also the person didn't include any context what makes them unusable or 'suck' - I think it's good that there's some choices but what I am inclined to agree with, is that they exist - and sorry, AMD doesn't look like they contributed anything...maybe have some employees look at the projects and 'pick' one to help or something? I don't know.

I don't think 'overclocking' is really a 'thing' anymore - since these gpus are already overclocked quite a bit already? Also, regardless of whether it's nvidia or amd gpus (dunno about intel gpus), the higher tiers are already hot and high power when stressed. I think more users want to set power limits, voltages and fans (i.e. fan control). These are basic settings for gpus, aren't they? In Windows, there's quite a bit of choice but in Linux, it's very limited afaik, regardless of whether it's nvidia or amd - but from my impression, nvidia had some good programs or options in comparison.

Personally, I think any Linux user would welcome anything AMD contributed and if you limited it to just one DE or write it in Qt or GTK or whatever - whatever is easiest - you should pick. I tend to choose my distro or DE based on what is most convenient or what works with my hardware the best - and I'm not mad if I have to switch DEs/distros sometimes.

I know someone complained here - about an open source project program - that was written in GTK - but, I suspect that is a minority - if it's a really good program, then ppl will use it (I think).

[agd5f]

I don't think 'overclocking' is really a 'thing' anymore - since these gpus are already overclocked quite a bit already? Also, regardless of whether it's nvidia or amd gpus (dunno about intel gpus), the higher tiers are already hot and high power when stressed. I think more users want to set power limits, voltages and fans (i.e. fan control). These are basic settings for gpus, aren't they? In Windows, there's quite a bit of choice but in Linux, it's very limited afaik, regardless of whether it's nvidia or amd - but from my impression, nvidia had some good programs or options in comparison.

I think it's somewhat the opposite. Everyone uses the vendor provided tools on windows because that is mostly all there is. In a lot of cases there is not standard OS provided API on windows to the only real option is the vendor tool. On Linux there is a lot of choice and also a lot of standardization. E.g., Linux has the hwmon subsystem that provides a standard API for fan control, power caps, temperature/voltage/power metrics, etc. There are tons of tools out their to display these metrics or adjust them. You can see all of the data on your system for all devices (CPU, GPU, motherboard, NIC, nvme, etc.) using a standard API. No one is clamoring for an ASUS or Gigabyte specific GUI to control the fans and read the temperatures on the motherboard, or AMD or Intel specific GUI to control the CPU fan. From my perspective having a separate vendor specific tool for every device on your system seems like a huge hassle.

Nvidia is a bit of an outlier because they are not upstream and only provide out of tree drivers so they are not behold to the governance requirements of any of the open source projects they interact with. At the same time, they also don't necessarily provide a public API or use any standard API to access that functionality, so the only option available is to use their tool. One could argue you have less choice on nvidia because your only option is their tool.

[Panix]

I think it's somewhat the opposite. Everyone uses the vendor provided tools on windows because that is mostly all there is. In a lot of cases there is not standard OS provided API on windows to the only real option is the vendor tool. On Linux there is a lot of choice and also a lot of standardization. E.g., Linux has the hwmon subsystem that provides a standard API for fan control, power caps, temperature/voltage/power metrics, etc. There are tons of tools out their to display these metrics or adjust them. You can see all of the data on your system for all devices (CPU, GPU, motherboard, NIC, nvme, etc.) using a standard API. No one is clamoring for an ASUS or Gigabyte specific GUI to control the fans and read the temperatures on the motherboard, or AMD or Intel specific GUI to control the CPU fan. From my perspective having a separate vendor specific tool for every device on your system seems like a huge hassle.

Nvidia is a bit of an outlier because they are not upstream and only provide out of tree drivers so they are not behold to the governance requirements of any of the open source projects they interact with. At the same time, they also don't necessarily provide a public API or use any standard API to access that functionality, so the only option available is to use their tool. One could argue you have less choice on nvidia because your only option is their tool.

I think I understood most of what you wrote - at the commoner level. But, tell me if I'm mistaken but it's my impression that gpu vendors - well, some of them - DO provide vendor-provided GUI to control fans at least (probably voltage, too) - there's also 3rd party ones of course - most of these are written with Windows in mind but that is obviously because of the user base and audience?

I wasn't requesting/demanding/pleading for this, either. Just a basic 'aio' gui that works with the 'amd' internals. I understand that Nvidia makes it extra difficult for developers in Linux - for a better GUI than the outdated/universally despised 'Nvidia control Panel server' - but, I heard/read of 3rd party options - a dev created a program 'Green With Envy' which worked well - however, you are right - Nvidia makes it so difficult and complicated to maintain - that the dev has decided to quit and is apparently switching to an AMD card.

My hope or question is that AMD helps out the devs who have created and developed the programs and GUIs - ones that have been profiled and reviewed on this forum - or offer their own. 'kay, I guess I will shut up now about this. Apologies.