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

#241

Post by nameless912 » Sat, Dec 10, 2016, 5:47 PM UTC

crb002 wrote: post #238

Seems kind of silly that the Kernel should be nanny to all drivers. Drivers to me should host their own repo, and provide proper integration tests before they are blessed. Some sort of --externDrivers="foo2016" flag you pass to the build. No drama on how horrid their code is because the Kernel shouldn't care.

It's not that easy though. The kernel doesn't have a stable internal API, which means that it's nearly impossible to maintain an out-of-tree driver. The kernel operates on a classic google-style monorepo model (well, maybe google-style isn't a good term, after all, they certainly didn't invent it...) because when someone changes a kernel API they are obligated to ensure the change is propagated to all related code. You get maintenance basically for free in the kernel, but only if you build an in-tree driver.

FWIW, a proprietary "binary blob" driver has already been available for a while that was built out-of-tree, but it constantly has to be updated for the latest kernel and doesn't release a version for every single kernel, so it's very difficult to use it unless you either 1) specifically use the exact version the driver requires (which is ridiculous-you should be able to dictate which kernel version you want) or 2) use a well-known and well-supported repo (which limits your choice as well). Ultimately, the best way to get driver support into the kernel is to go through the standard kernel channels.

And also FWIW, the kernel does care about how drivers are written-even if the driver is out-of-tree, its possible shittiness reflects back (totally unfairly, I know) on the kernel. By having a gatekeeper for device drivers, they can ensure that the kernel is as stable as possible for as many users as possible, and that's a laudable end goal. It's also orthogonal to wide hardware support, as all that was required in this situation was for AMD to adhere to the guidelines properly, but they didn't do so, so they have no right to be upset that their code got rejected.

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

#242

Post by nameless912 » Sat, Dec 10, 2016, 5:48 PM UTC

sangnoir wrote: post #135

gumby wrote: post #40

I didn't see where Dave slagged AMD's culture, and I think everyone was very polite and detailed about why this doesn't fit. I understand why AMD wants to have one code base, but the kernel needs to have one consistent code base and style and can't afford to do otherwise. There's nothing stopping AMD distributing the code, it just won't be upstreamed.

Because rather than believing the AMD kernel devs are misguided about the kernel, he suspects the higher-ups at AMD are not listening to them. See https://news.ycombinator.com/item?id=13143371

That's probably far more accurate and much more fair than assuming they're just shit programmers.

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

#243

Post by snarfy » Sat, Dec 10, 2016, 6:07 PM UTC

calinet6 wrote: post #235

calinet6 wrote: post #97

Earlier quoted context omitted.

Define "good" and "software."

This got into negative territory, but I was being serious. Define "good." Is quality a thing just defined by code style and properness, or is it defined as fitness for a purpose, connection to human use and usefulness, usability or function, or lack of defects to the end user? Define "software." Is software just code, or does it also include the experience the code generates for the user? Is software only considered…

Developers are also users, and a part of the application they use is the source code. Having good quality source code benefits all users, not just developers. Linux is where it is today because of the quality of the code. Things like "use and usefulness, usability or function" have different meanings to a developer looking at the source code.

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

#244

Post by digi_owl » Sat, Dec 10, 2016, 6:11 PM UTC

Waterluvian wrote: post #218

Didn't the AMD guy respond months ago that he expects they'll reduce it to like 30k loc? What happened to that? Not that this is the crux of the problem, just curious.

It is not about compromise, it is about the long term maintainability of the code.

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

#245

Post by geezerjay » Sat, Dec 10, 2016, 6:23 PM UTC

izacus wrote: post #234

geezerjay wrote: post #152

Earlier quoted context omitted.

> The kernel essentially demanded they drop the idea of cross-platform driver Don't you agree that it is very silly to try to force cross-platform code into the very source of a very specific platform? After all, the people working for that platform need to actually maintain that code.

No, it works very well for nVidia.

NVidia does nothing of the sort. NVidia's driver is a kernel module they distribute themselves, and that NVidia users need to download and install themselves.

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

#246

Post by floatboth » Sat, Dec 10, 2016, 6:37 PM UTC

rasz_pl wrote: post #228

>We don't happen to have the resources to pay someone else to do that for us. Typical AMD bullshit. They do have resources for developing garbage like 'Gaming Evolved App' just to abandon it 6 months later tho.

Gaming Evolved was not developed by AMD, it's a branded version of raptr.com.

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

#247

Post by notalaser » Sat, Dec 10, 2016, 7:36 PM UTC

shakna wrote: post #210

notalaser wrote: post #180

Earlier quoted context omitted.

I don't know if HALs in the kernel would have been the smart thing to do here (I'm not familiar enough with the problem to comment; generally, abstracting hardware access behind a HAL is a smart thing, but "generally" is a really bad snare trap). On the other hand, I'd really love to see the Linux team getting the same treatment that Microsoft gets whenever they encourage lack of portability, even where portability w…

> I'd have expected to see questions like "why did these guys write the whole fsckin thing, all 100,000 lines of it, and only found out it's not upstreamable now" AMD was told 6 months ago that it wouldn't be merged if they didn't follow certain guidelines. Then they didn't follow the guidelines. What bothers me here, is the way AMD's management has handled the whole thing. It seems like management demanded it be a c…

I agree that there is room for disagreement between the two approaches. However, I don't think that AMD did things this way just because of short-sighted management. A HAL-like layer is a solution that I've seen or heard of in a lot of places, from a lot of hardware manufacturers that want to support Linux.

It may seem -- and may well be -- a sub-optimal solution, but it's not worse than what we have now, and AMD looks willing to commit to the long-term support of the HAL and the drivers. This is likely something that they want to do not just because they're lazy and would rather spend the money on something else -- it's likely that their management genuinely sees the development and maintenance of an entirely unabstracted set of drivers for Linux as inefficient, especially when you look at how much money they make out of it. And they aren't entirely wrong.

Deucher's remark about the Red Hat silo may look malicious and abrasive, but it has a glimpse of truth. I could make a really cool photo album by taking snapshots of developers and managers who are only familiar with Windows and hear about the challenges involved in writing (and upstreaming) a non-trivial Linux driver.

I'm not saying that the driver should have been merged as it is just because there's no alternative. I do think, however, that it's a little presumptuous to think its architecture is the way it is just because managers are stupid. Maybe a third option, that's not HAL but also addresses the concerns and requirements of AMD exists.

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

#248

Post by solatic » Sat, Dec 10, 2016, 8:35 PM 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…

It's the labor theory of value in action. "We put in the labor, labor is intrinsically worth something, because we're giving you something that's worth something, it should be appreciated by you and by the wider community."

But that only works when you're in the programming equivalent of a 20 member socialist commune. It doesn't work at scale, and the Linux kernel is the effing king of large open-source projects. At scale, you must have standards to ensure the value added is higher than the cost of maintenance. Who's going to set the standards if not the kernel maintainers? The contributors? That's anarchy, leading to collapse. The wider community, in some democratic fashion? Easiest way to kill momentum and thus kill the project.

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

#249

Post by duaneb » Sat, Dec 10, 2016, 8:55 PM UTC

AlphaSite wrote: post #98

Dylan16807 wrote: post #96

Earlier quoted context omitted.

Writing the software that makes your hardware work is much more of a revenue-based issue than a profit-based issue. Even if you're losing money you need to balance your development budget, and not cut any segment too far.

Their revenue is from Windows, Apple and Cknsoles, not from Linux.

It's impossible whether to tell if it'd be better if their drivers sucked less. It's certainly a massive barrier to Linux being usable.

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

#250

Post by geezerjay » Sat, Dec 10, 2016, 9:14 PM UTC

tankenmate wrote: post #233

XorNot wrote: post #175

Earlier quoted context omitted.

Gotta say this is my takeaway. If near latest kernels work with nvidia, I'll buy nvidia in the future (I'm all amd at the moment).

And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none). This is the reason that the AMD open source drivers are within 10~20% of performance of the closed source drivers on a number of chipsets (not all) whereas on Nvidia chipsets the open source driver is often just to boot a system and get X running enough to install the closed source driver.

> And yet AMD releases far more of it's specification for its chipsets than Nvidia does (which releases next to none).

That is only relevant if any third-party has any interest in taking up the challenge of developing an alternative driver.