Live data from Hacker News

AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

lists.freedesktop.org

21–30 of 284 posts

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#21
post #10
post #8

Did I miss the mud-slinging and corporate culture bashing from the original rejection? I can get the AMD dev being a bit sour by the whole situation if they personally spent time working on this rejected patch, but damn.

There were certainly implications that the AMD coders were making technically compromised decisions: > The reason the toplevel maintainer (me) doesn't work for Intel or AMD or any vendors, is that I can say NO when your maintainers can't or won't say it. And telling them to sit in a corner and really THINK about what you've done, young man: > I'd like some serious introspection on your team's part on how you got into…

> ... but I'm not the one who got the email telling me my months of work ... would not be merged.

See, the thing is that they were told previously -- back in February? March? -- that this wasn't gonna happen. Instead of trying to work out a better way forward, AMD effectively ignored that, went back to work, and just now came back and said "here's 90k LOC, please merge".

Dave replied -- rightfully, in my opinion -- "no".

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#22
post #19

Earlier quoted context omitted.

If it was a big secret that this was how Linux worked and it took the companies by surprise, I could see how this could be a bad thing, but it never has been: Linus has always been very upfront that he is Benevolent Dictator for Life and always has the last word. Don't get onboard if you don't like that system.

Then all the Linux fans that complained to AMD that they don't deliver open source drivers should from now on better shitstorm the kernel maintainers, since AMD delivered.

There is absolutely nothing preventing AMD from delivering their own open-source drivers to their customers.

They want it in kernel, however, and that means they have to play by the in kernel rules.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#23
I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect.

His arguments seem really weak. Apparently the AMD team believes that the kernel should accept this code despite it not meeting their standards because:

* Otherwise they'll write angry blog posts about how mean the kernel maintainers are.

* They're a primarily Windows shop.

* They don't have the resources to do it right.

* They don't have the time to do it right.

* They're 'trying' to do the right thing.

* They believe that AMD is a big enough company to get special treatment.

* "But Andrrroid gets special treatment"

* There are lots of people with unreleased hardware that desperately need driver support.

* They're doing in wrong, but the current kernel maintainers are doing it wrong in a different way so it should be okay.

* Graphics drivers are what's preventing the 'year of the Linux desktop'.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#24

What I don't get is how one kernel maintainer can make such a massive decision that affects all of Linux. That's some near-totalitarian level of power. After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.

That's some near-totalitarian level of power.

AMD is perfectly within their rights and abilities to ship an out-of-tree driver. As I understand it, DKMS exists to make that use case easier for end users. The popular consumer-facing distros would probably make it easy as dirt to install too.

The difference between that and upstreaming into the kernel is primarily shifting some of the the maintenance burden onto the kernel developers. That comes with the condition of adding stakeholders to the driver design, not just using them as a code dumping ground.

"Totalitarian" seems a bit over the top.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#25

The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception. Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a…

Then again, we're not talking about some wierd network card driver here.

We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues.

While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog happening here on how to resolve problems both sides have, just a repeat of posturing which has historically brought us awesome things like binary blob drivers that only work with single version of kernels (yes, I'm looking at you every ARM GPU ever!).

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#26
post #23

I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments see…

That's a lot of strawmen you managed to build here :/

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#27
post #13

I do feel Dave went a bit over the top in his response. If he keeps it technical it's easier to fix, people want to see their stuff merged. When he makes it personal (which he kind of did) it turns people off. That being said, I do think Dave probably made the right call, but I also think he may need to compromise on this one. That being said, AMD should strategicly try and get their GPUs supported. Couple that, with…

From his point of view the AMD guys were told that this code wouldn’t be merged as is six months ago and now they come back with a massive code drop and very effectively put him in the position of having to be the bad guy. I think we’d all have some sharp words we’d like to use in that situation even if the better part of our natures might counsel us to keep them to ourselves.

The kernel essentially demanded they drop the idea of cross-platform driver (which is what makes nVidia drivers work so well on Linux and is keeping them in lockstep with Windows releases) and maintain a full separate copy with a small team.

It was unrealistic six months ago as it is now. And yet, I still don't see a constructive debate from Linux (or AMD) side on how to sync the goals. All I see is Linux people posturing about how they don't want to be the second platform and AMD refusing to rebuild the driver just for them.

These kind of attitudes bring us awful situations like Android Linux devices each having a broken fork of Linux kernel to accomodate closed proprietary blobs because neither side is ready to step together.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#28
post #26
post #23

I really don't understand why AMD cares so much about getting their driver upstreamed. If their code doesn't meet the kernel standards and they don't want to fix it then just package it up as kernel module and ship it like Nvidia does. Distributions will package it using DKMS and other than some occasional troubleshooting they wont even notice. It's really no difference than Windows in that respect. His arguments see…

That's a lot of strawmen you managed to build here :/

That list really is sourced from Alex' email.

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#29
> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android.

Could someone here fill in the details for the uninitiated? Do the kernel devs feel a pressure for the kernel to stay relevant in the Android world?

Re: AMD responds to Linux kernel maintainer's rejection of AMDGPU patch

#30
post #25

The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception. Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a…

Then again, we're not talking about some wierd network card driver here. We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog hap…

AMD was told in February that they would have to obey kernel code standards / no HAL.

In late October they dropped a steaming pile of 100k lines of code with a HAL and are whining it isn't getting merged.

The solution is AMD keeps code out of mainline or obeys kernel code standards.

Post reply on HN