I Had A Tough Time Deciding What GPU To Use On My Main Fedora Linux Workstation

[duby229]

I think what's going on here is that AMD believes that since a GUI control panel has so many functional use cases a community driven project will pop up out of nowhere from nothing. The problem is its been ten years and the drivers don't expose some of the basic functionality a GUI control panel needs, like overriding anti-aliasing for example. I think that's the reason why it hasn't been done yet. AMD is going to have to expose required configuration details and then they are going to have to develop a GUI for it. I believe they are the only ones with the expertise to do it. And it's plainly obvious they aren't going to, probably ever.

[schmidtbag]

I think what's going on here is that AMD believes that since a GUI control panel has so many functional use cases a community driven project will pop up out of nowhere from nothing. The problem is its been ten years and the drivers don't expose some of the basic functionality a GUI control panel needs, like overriding anti-aliasing for example. I think that's the reason why it hasn't been done yet. AMD is going to have to expose required configuration details and then they are going to have to develop a GUI for it. I believe they are the only ones with the expertise to do it. And it's plainly obvious they aren't going to, probably ever.

I don't think AMD expects any favors from the community, but a GUI tool isn't a necessity, so it isn't a high priority. I figure even Crossfire will get supported before a GUI tool. I do think they would eventually work on a GUI tool once the hardware is feature-complete.
On the other hand, you may be right because if Intel, a much larger company with less stress about hardware functionality, isn't working on it either.

[duby229]

I think people fear registry-like things. And that's the reason more less. A control panel would have to have something like that to build on.

[schmidtbag]

I think people fear registry-like things. And that's the reason more less. A control panel would have to have something like that to build on.

I have for a while legitimately considered making one, except compatible with all Mesa drivers (where it would adapt based on the GPU you have). There are a handful of problems though:
1. I don't know exactly what everyone would be looking for. As someone who doesn't really care about most features this would offer (but still respects people's needs for them) I would want to include as much as possible. But, what should be implemented is a bit of a gray area, since kernel flags, driconf and xorg.conf seem to do many things people are looking for. Or, would access to those features be desirable, too?
2. Much like driconf, I would want this to adapt to the changes in Mesa without me having to manually update it. The problem is, I don't know where to get all of this information. I would need unified source(s). I'm aware of this which should be relatively easy to parse, but that's far from complete.
3. I'm not sure if people are expecting more than just environment variables.

[duby229]

I have for a while legitimately considered making one, except compatible with all Mesa drivers (where it would adapt based on the GPU you have). There are a handful of problems though:
1. I don't know exactly what everyone would be looking for. As someone who doesn't really care about most features this would offer (but still respects people's needs for them) I would want to include as much as possible. But, what should be implemented is a bit of a gray area, since kernel flags, driconf and xorg.conf seem to do many things people are looking for. Or, would access to those features be desirable, too?
2. Much like driconf, I would want this to adapt to the changes in Mesa without me having to manually update it. The problem is, I don't know where to get all of this information. I would need unified source(s). I'm aware of this which should be relatively easy to parse, but that's far from complete.
3. I'm not sure if people are expecting more than just environment variables.

Exactly. Some of what people would like in a control panel is implemented in X, like tearfree for example. Other things like toggling the OSD are environment variable and driver specific. Other things are configured through sysfs or monitored through proc. And even more stuff isn't even possible right now like overriding anti-aliasing. You would have to preconfigure some kind of registry-like database thingy first. And every GPU driver would have to configure that database thingy itself for driver specific stuff. It almost would have to be a vendors control panel where they can do what they want. Or everyone in the industry would have to get together and work as a community.

[duby229]

Desktop tearing in Xfce happens when the display compositing is not enabled. You have a tab for it in the Window Manager Tweaks dialog. You do not much use the nvidia control panel, just set the opengl performance to max. This could be a default setting. You have enough display related settings in the Settings/Display dialog.

That's just not true. So the compositor basically just acts like a second framebuffer, but those frames still need to be displayed at vertical sync. You definitely still need tearfree driver options so that NTSC and anything else that has a framerate different from your refresh rate, including games, don't tear. A compositor by itself does -NOT- fix tearing.

[vito]

My hope is DC will be merged sooner than later, but in the mean time it is actually pretty easy to get HDMI audio on Polaris cards working on Fedora - I use it every day. Just follow the instructions on mystro's copr repo (1):

sudo dnf copr enable mystro256/amd-mainline-kernel sudo dnf update -x kernel* sudo dnf update --disablerepo=updates
1: https://copr.fedorainfracloud.org/co...ainline-kernel

[agd5f]

As I've said before, the biggest obstacle to having a display configuration GUI is just the shear number of desktop environments out there and the fact that nearly all of them currently have their own display control tools that store the user's display configuration differently. On top of that, each desktop environment periodically changes how they store they display configuration. Next add Xorg and wayland and figure out how to support both. With all of these variations, if you change the display configuration in the desktop's display GUI, you might break the configuration set up by the vendor specific GUI or vice versa. We ran into this all of the time with fglrx. Linux really need a standard mechanism to store the display configuration across desktop environments otherwise it's hard to support them all reliably.

Beyond display configuration, most of the rest of the GPU configuration is exposed via standard mechanisms (e.g., drirc xml for 3D driver options and standard hwmon interfaces for thermal and fan control). It would be nice to have a common GUI for all vendors that use these common interfaces.

[Tomin]

I have for a while legitimately considered making one, except compatible with all Mesa drivers (where it would adapt based on the GPU you have). There are a handful of problems though:
1. I don't know exactly what everyone would be looking for. As someone who doesn't really care about most features this would offer (but still respects people's needs for them) I would want to include as much as possible. But, what should be implemented is a bit of a gray area, since kernel flags, driconf and xorg.conf seem to do many things people are looking for. Or, would access to those features be desirable, too?
2. Much like driconf, I would want this to adapt to the changes in Mesa without me having to manually update it. The problem is, I don't know where to get all of this information. I would need unified source(s). I'm aware of this which should be relatively easy to parse, but that's far from complete.
3. I'm not sure if people are expecting more than just environment variables.

That's what I've been thinking as well. We should really create a wiki page or something to collect these.

Beyond display configuration, most of the rest of the GPU configuration is exposed via standard mechanisms (e.g., drirc xml for 3D driver options and standard hwmon interfaces for thermal and fan control). It would be nice to have a common GUI for all vendors that use these common interfaces.

I don't think that the GUI needs to do any display configuration, just the other 3D graphics and card settings that are not desktop specific. Probably some power and clock related information too.

[smitty3268]

I don't remember discussing anything that would justify you sounding so PO'ed about it.

I'm really not PO'd. I just thought you made it clear you were very uninterested in what i had to say, so i gave up on the subject.

Our "secret plan" is for the display team (not the Linux team) to keep working on restructuring as discussed publicly with the maintainers, as we have said before. It's a slow process because any change needs to be accepted & validated on a number of different platforms but AFAIK it is still making progress and we will be doing another sync-up this week.

Our "other secret plan" is to make it easier to install out-of-tree open source drivers in the short term by leveraging some of the work done for the AMDGPU-PRO stack - again we have talked about this a few times already.

What am I missing here ? Is there some other secret plan that even we don't know about ?

Those aren't plans. They're goals and aspirations, and there is a difference. A plan is how you intend to reach those goals, and that's what is secret. Unless you wish to now open up and show the bullet points that show how you can achieve those goals, with approximate dates? I'm assuming not.