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

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

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

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]

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.

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

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

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