AMD responds to Linux kernel maintainer's rejection of AMDGPU patch • Hacker News Board

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

#61

Post by forgottenpass » Sat, Dec 10, 2016, 1:43 AM UTC

izacus wrote: post #31

I think this is a great situation to quote Linus on Linux supporters inside companies (not 100% same, but I think related): (on litigation against companies that contribute) > Anyone in the company that pushed to use Linux is now seen as "wrong" and instantly is pissed off that external people just messed up their employment future. > - Anyone in the company that resisted the use of Linux (possibly in ways that cause…

All with a single "no". Not "We can't accept this, let's talk about how to make us both happy". With that he gave new ammunition to every manager at every large hardware corporation [...] I'm not blaming Dave for refusing the patch for tech cases. I AM blaming him for refusing it so flatly and not actively working more with AMD to get the situation fixed.

He's been giving the "let's talk about how to make us both happy" answers for months and months. That's not a single "no." That's not flat. What that is, is a lot of design review and "soft nos." (I do still agree that it's ammunition. People who are looking for a reason not to contribute to the kernel will have no problem using this email out of context either.)

Other than eventually "taking one for the team," caving, and merging what AMD wants, what level of support are you talking about here? As far as I can tell, your post takes the stance that a "hard no" to any patchset is going too far.

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

#62

Post by freeone3000 » Sat, Dec 10, 2016, 1:45 AM UTC

izacus wrote: post #27

pja wrote: post #13

Earlier quoted context omitted.

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 post…

The kernel demanded they drop the idea of a cross-platform driver to get merged into the kernel. They can still develop a standalone driver module, same as everybody else. Code doesn't need to be in kernel to run.

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

#63

Post by phkahler » Sat, Dec 10, 2016, 1:57 AM UTC

bhouston wrote: post #55

fbreduc wrote: post #53

Earlier quoted context omitted.

> They don't have the resources to do it right. Honestly I hear this quite often from big companies and it always is the biggest load of BS ever..

It is hard to get resources to do things right sometimes, even in big companies. There are a lot of competing priorities.

>> It is hard to get resources to do things right sometimes, even in big companies. There are a lot of competing priorities.

AMD has the resources. The problem seems to be getting them allocated to this particular issue. I also find your phrasing interesting. Doing it "right" is always my top priority and every compromise from that is considered and balanced. In my experience, not doing it right is almost always more costly but sometime necessary to appease someone. It's interesting that Dave is standing his ground against a multi-billion dollar company for their own long-term good - or at least what he perceives it to be.

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

#64

Post by jrk » Sat, Dec 10, 2016, 1:58 AM UTC

pmelendez wrote: post #60

izacus wrote: post #27

Earlier quoted context omitted.

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 post…

> which is what makes nVidia drivers work so well on Linux Maybe for you, every kernel upgrade I have done in the past would break my desktop for a day or two until a patch is released. Not too mention oddities and artifacts, I get from time to time. Things that I find unacceptable and embarrassing if it happens on Windows or Mac and I have to learn to live with it on Linux. I am probably out of luck but I think I wo…

Breaking on every kernel upgrade is a configuration issue (and a result of Linux's driver model); the "quality" of the NVIDIA Linux driver being discussed is an issue of the actual performance, compliance, stability, and feature parity/freshness relative to others, once configured correctly.

Reconfiguration/rebuild on every kernel update is definitely a hassle, and the NVIDIA scripts which try to automate the process still occasionally fail (IME, generally due to conflicts with the system package manager constantly deciding it knows best and trying to displace them with its own versions). But that's essentially an unavoidable consequence of combining out-of-tree drivers Linux's extreme no-stable-driver-ABI-ever design which requires all drivers to be rebuilt directly against the exact current kernel source: you always have to rebuild the bindings on kernel upgrade. The bindings can still be maintained by the distro vendor and its package manager, so they're centrally rebuilt (and fixed if needed), and updated in lock step with the kernel. This works well in Ubuntu, at least, these days. But absent that, the Linux model fundamentally requires local rebuild automation (or full manual rebuilds), which is prone to breakage, like any other "just download and rebuild from scratch against a new version" you've ever done, kernel/driver or otherwise.

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

#65

Post by jinmingjian » Sat, Dec 10, 2016, 2:09 AM UTC

I also stand on the kernel maintainer's side.

Kernel is not your AMD's kitchen-sink:) They are always fighting for any holes. The maintainers become the maintainers because the community think they has the qualified capabilities. The best way is to argue in technical side: for example, why you should have such complexities, how to control the complexities or something like. No technical response makes non-sense and low down your reputation in the community.

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

#66

Post by vertex-four » Sat, Dec 10, 2016, 2:09 AM UTC

For the record... AMD are perfectly welcome to publish their patches and try to convince Ubuntu/Red Hat/etc to include them in their own forks of the kernel (no distro uses a completely vanilla kernel, they all have their own patchsets they apply on top of it for various reasons). The only great loss here is that AMD can't force kernel developers to maintain substandard code, and will have to do it themselves.

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

#67

Post by cypher543 » Sat, Dec 10, 2016, 2:10 AM UTC

smnc wrote: post #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…

I don't know the details either, but honestly, I'm amazed that Google hasn't just thrown Linux out and built a microkernel with a Linux-compatible syscall API. That way there's a single binary that only cares about standard ARM things like memory management and scheduling and doesn't require hardware vendors to tweak it for every new SoC. The SoC-specific drivers can be written and updated separately just like apps. Maybe then it would be easier for vendors to keep their shit updated so I don't have to throw out my perfectly good phone just because a company doesn't feel like porting their changes to a new kernel version.

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

#68

Post by phkahler » Sat, Dec 10, 2016, 2:11 AM UTC

jrk wrote: post #64

pmelendez wrote: post #60

Earlier quoted context omitted.

> which is what makes nVidia drivers work so well on Linux Maybe for you, every kernel upgrade I have done in the past would break my desktop for a day or two until a patch is released. Not too mention oddities and artifacts, I get from time to time. Things that I find unacceptable and embarrassing if it happens on Windows or Mac and I have to learn to live with it on Linux. I am probably out of luck but I think I wo…

Breaking on every kernel upgrade is a configuration issue (and a result of Linux's driver model); the "quality" of the NVIDIA Linux driver being discussed is an issue of the actual performance, compliance, stability, and feature parity/freshness relative to others, once configured correctly. Reconfiguration/rebuild on every kernel update is definitely a hassle, and the NVIDIA scripts which try to automate the process…

That's why I switched to the open source nVidia driver long ago. I got tired of upgrades screwing up the driver. It's not a configuration issue, it's because the other nVida driver doesn't get rebuilt along with the kernel due to not being upstream.

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

#69

Post by CamperBob2 » Sat, Dec 10, 2016, 2:13 AM UTC

Spivak wrote: 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…

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

I loved that line from his post, in particular. "We have the resources to design a billion-transistor GPU, but not to write a Linux driver for it."

Poor management on AMD's part does not constitute an emergency on the Linux kernel's part.

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

#70

Post by ajarmst » Sat, Dec 10, 2016, 2:18 AM UTC

AMD's response is 25% talking about unrelated Exynos code, 35% sarcastic complaints about Linux culture and 20% explaining why its naive to care about code quality and style. It concludes with a barely veiled threat about how they won't change and that not merging their code is what is keeping Linux off the desktop. I think we're done here.