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

[chithanh]

Are we still talking about DAL upstreaming ? What do those people think we are doing relative to what they think we should be doing ??

I think much of the criticism is about the confusion and complexity surrounding this topic.

AMD has at least two separate public kernel trees with non-mainlined new hardware/function support (amd-staging and rock-kernel-driver). There are several distro package repositories (packages.amd.com which was recently moved/merged to repo.radeon.com and at least one other I don't remember right now). AMD leaves users mostly in the dark about what is shared and what is unique to each tree/repository.

Then the kernel trees appear not maintained very well. Not even the fixes to the respective stable branches are applied. The binary repositories also appear to lag somewhat behind their source trees.

[bridgman]

Perhaps what you're saying is that we should be able to parse through all the code and reviews ourselves and figure all this out.

Absolutely not - I was responding to duby229's post where he stated that "a lot of people think what you're doing now is overly complex", which implied that at least some of those people had already parsed through the code and reviews themselves.

It wouldn't make any sense for them to "think what we are doing now is overly complex" if they didn't already know what we were doing and have an alternative plan in mind.

That isn't a plan, it's a goal.

I would call it "a one line summary of the plan". We have never published internal plans - we would rather spend the time it would take for regular sanitizing & legal review etc... on improving the drivers.

How are you going to make it easier? What work are you leveraging?

Leveraging the KCL/DKMS plus build/packaging/installer work done for AMDGPU-PRO (sorry, I had said that a few times in other threads so didn't repeat it here), combining open and closed userspace components into a single release then allowing the user to install either all-open or hybrid.

[smitty3268]

OK, you want the schedule not the plan then. We don't normally publish schedules because they change as other project priorities & schedules shift around and that tends to freak people out who aren't used to working in large companies with shared engineering teams. The usual "we do not comment on unreleased products" thing.

We do publish the WIP source code though, and we communicate with the maintainers in public, so I'm not sure where the "secret" thing comes from. Are you saying you want some kind of distilled-down-for-executives reporting ?

I know you won't share the schedule. That would be a great way of sharing your plan, but in lieu of that, how about a public list of bullet points summarizing the tasks that need to be accomplished? Then end users could follow along and mark off line by line as the OSS code shows up.

The more detailed the better. A 100 point plan would be awesome. I'd settle for 10 as a much quicker list. A single bullet point plan ("we're continuing to work on it until it's done") is not really a plan at all.

Perhaps what you're saying is that we should be able to parse through all the code and reviews ourselves and figure all this out. In that case, I respectfully disagree. I don't think anyone who's not a driver developer has the capability to do that. In fact, I'd bet not even someone like Dave Arlie could tell you exactly what's remaining on your list before you resubmit DC, for example. He might be able to guess at certain parts, but it's your developer team that is ultimately deciding when they think it's ready.

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

That isn't a plan, it's a goal. How are you going to make it easier? What work are you leveraging? How far away is this from reality, what's left to do?

[duby229]

Are we still talking about DAL upstreaming ? What do those people think we are doing relative to what they think we should be doing ?

Or is it just a case of "they don't know what you are doing 'cause they haven't looked at the evolving code, and they don't know what you should be doing because they didn't look at the code in the beginning or go through all the discussions with maintainers, but they are sure that what you are doing is overly complex and taking too long" ?

No but you did and you know and you are an AMD representative. So instead of answering like this:

Sorry, what did I not want to hear ? Maybe I'm not remembering because I was fighting a bad cold/cough/whatever but I don't remember discussing anything that would justify you sounding so PO'ed about it.

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 ?

Which didn't answer anything and essentially all those words boil down to, We're doing what we were doing, even though it doesn't make sense (to users), and it's already been long overdue. DC is a requirement on new hardware that is available to buy today. Shouldn't your own responses clue you in to that? I mean they were your words after all. I'm not saying your plans or goals are actual secrets, but for all we can see it might as well be. It's either that or you guys really don't know. That's much more scary.

EDIT: It -is- overdue, You can buy hardware already.

[bridgman]

Here's what I think, -a lot- of people think what you're doing now is overly complex and it's taking too long. And they can't fathom why.

Are we still talking about DAL upstreaming ? What do those people think we are doing relative to what they think we should be doing ?

Or is it just a case of "they don't know what you are doing 'cause they haven't looked at the evolving code, and they don't know what you should be doing because they didn't look at the code in the beginning or go through all the discussions with maintainers, but they are sure that what you are doing is overly complex and taking too long" ?

[duby229]

OK, you want the schedule not the plan then. We don't normally publish schedules because they change as other project priorities & schedules shift around and that tends to freak people out who aren't used to working in large companies with shared engineering teams. The usual "we do not comment on unreleased products" thing.

We do publish the WIP source code though, and we communicate with the maintainers in public, so I'm not sure where the "secret" thing comes from. Are you saying you want some kind of distilled-down-for-executives reporting ?

Distilled down for technical end users would be better. Here's what I think, -a lot- of people think what you're doing now is overly complex and it's taking too long. And they can't fathom why. And then when they ask you, the only answer they get is "much the same", which doesn't answer anything. So then leaving a technical user to his own imagination leads him to imagine technical things, obviously. That's why the word secret keeps getting used. It "feels" that way, because nobody has had the question answered. Either it's a secret or you guys really don't know. If it's a secret, that somehow feels better than you guys don't know.

Honestly you would be better off to re-evaluate your stance on informing educated end users.

[bridgman]

OK, you want the schedule not the plan then. We don't normally publish schedules because they change as other project priorities & schedules shift around and that tends to freak people out who aren't used to working in large companies with shared engineering teams. The usual "we do not comment on unreleased products" thing.

We do publish the WIP source code though, and we communicate with the maintainers in public, so I'm not sure where the "secret" thing comes from. Are you saying you want some kind of distilled-down-for-executives reporting ?

[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.

[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.

[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.