Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.freedesktop.org

Post reply on HN
Print view View original

201–210 of 284 posts

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

#201

Post by mslusarz »

bostik wrote: post #157
serge2k wrote: post #43

Earlier quoted context omitted.

why does AMD need to be in the kernel? Why can't they release the way nVidia does? or open source it, develop along with upstream but don't make it part of upstream.

You're asking a question with a very complex answer. I'll start with a short answer - AMD wants to have at minimum a reasonably good baseline functionality on linux, out of the box. If that answer doesn't make much sense, please read on for the complex bits. To provide some historical context, Linus gave a VERY public, VERY brutal rant on NVIDIA and their drivers four years ago.[0] At the time, NVIDIA's closed driver…

Although you don't say it directly but by saying that "The open drivers (nouveau) were slow and far behind in features." and then that the situation improved because of Nvidia involvement you are not being honest.

Nvidia hasn't improved performance or contributed features to nouveau.

Their changes are limited to code that is mobile chip-specific and from time to time they contribute some reliability fix that affects non-mobile chips, but only if benefits mobile.

Since Maxwell 2 (9xx+) their chips are designed to be hostile to nouveau, by requiring firmware loaded by the driver to be signed by Nvidia (hardware refuses to load firmware that wasn't signed by them). It means that without Nvidia blessing nouveau for example can't change the fan speed (but still can change clocks! how ridiculous it is?).

Nvidia contibuted signed firmware loading for non-mobile chips (so called SecureBoot), but only because it's also required by mobile. And they still have not released enough firmwares for desktop cards to be usable...

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

#202

Post by rbanffy »

AstralStorm wrote: post #130
freeone3000 wrote: post #62

Earlier quoted context omitted.

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.

But then they don't get the free lunch of kernel people maintaining and fixing their stuff. Which ends up in the same situation as older catalyst.

They can still get the free lunch, but they have to deserve it.

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

#204

Post by carlosrg »

This (and the replies on this thread from Linux supporters) shows how far away Linux is to be an acceptable alternative to Windows on the desktop. Instead of welcoming such a big hardware manufacturer with open arms and try to reach a compromise (and understanding that a company is not going to devote infinite resources to something that's not really as profitable as Windows, because you know, companies are created to make money, not lose it - they aren't not-for-profit orgs) the kernel maintainers choose to focus on purity and style crap. Well, enjoy your pure code and your 2% desktop marketshare. The next time you recommend Linux to someone, when he finds out his graphics card doesn't work well you can put the blame on the hardware maker as always.

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

#205

Post by aseipp »

TD-Linux wrote: post #179
cromwellian wrote: post #145

Earlier quoted context omitted.

They have, it's called Fuchsia. I think most the arguments for monokernels have weakened with age. You have L4 microkernels in every iPhone A7 processor now. The demands of security, crash resistance, and portability I think outweigh any small advantages in performance. We've got performance to waste these days, what we're lacking is more secure, crash resilient software.

And it's also not GPL, which means that vendors will be able to create fully proprietary versions of it. Yay?

The kernel developers don't really care about the GPL either, sorry to say. They don't go after violators, nor does the Linux Foundation, it seems. Linus himself has said that going after violators is in bad taste and poisons the well, vs just trying to be buddy-buddy and get them involved. Because obviously they'll just move away from Linux or whatever if you're a dick to them (except in the case where Linux effectively subsidizes their existence, making their product even possible). So, don't be a dick, and they'll come to you when you buy them a beer or whatever.

Which is clearly the reason why there aren't actually 14,000 different Android kernels and 2,000,000 different kernels for your $50 router running around. Because they all get involved, of course, from being so buddy buddy.

Naturally, this attitude costs Linux developers nothing at all for the most part, and keeps their lives easy (no legal shit, no hard times) -- while absolutely hurting users who can't get the source to their devices, and completely eviscerating the social/political capital of a license like the GPL, and all the people who use it.

When literally the biggest GPL success story can't get off their ass and prosecute license violators, who actually will care when you try to use it as a tool, one which actually has teeth to back it up? Why use a license if its major champion treats it like a complete piece of trash, a worthless bargaining chip, a chip which is only possible because of an effectively unique, lighning-in-a-bottle position?

If the kernel developers just don't give a shit about proprietary vendor kernel forks (I really, really don't think they really do, at least nobody with actual meaningful, large scale influence cares at all), and want to force involvement by "getting them in the cycle" and being buddy-buddy and just not-giving-a-fuck about people outside the source tree, making sure constant churn is how people have to keep up -- they should just use the BSD license.

It seems to have worked out pretty OK for LLVM, and this is basically their operating philosophy, too. At least then, maybe another project can arise that actually takes its own license terms halfway seriously...

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

#206

Post by hashhar »

Certhas wrote: post #191
notalaser wrote: post #178

Earlier quoted context omitted.

Linux drivers on the nVidia side are OK. I've had excellent performance, and no trouble with them for what I think are already 10 years now, if not more. Lack of driver support is not what's stopping people from releasing Linux games.

And they are closed source. AMD tried to go open source and upstream and found out that that is not viable, because they would need to duplicate a lot of work in order to avoid putting abstractions in the kernel. The upshot is, kernel developers have been complaining about nVidia lots for the route they took. When I install Linux on a reasonably recent desktop I still have to fiddle with boot options and/or blacklist…

This. Exactly this. The treatment AMD got from LKML was slightly deserved but doing that they alienated a hardware partner and indirectly set the precedent for doing closed source binary releases that use HAL anyway. It sucks for the consumers and that's what drives the installed base of Linux.

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

#207

Post by MayeulC »

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

Or even better, give us an open source out-of-tree driver, and wait. Someone in the community will do the cleanup and get it upstream eventually. For free .

While that's probably true, it won't happen overnight, and I understand their position of wanting it merged before rolling out new hardware, or more generally, as soon as possible.

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

#208

Post by hashhar »

notalaser wrote: post #180
jaredklewis wrote: post #133

Earlier quoted context omitted.

I'm sympathetic to BSD, but that seems like a lot of misplaced blame to me. Companies don't write FreeBSD drivers because there's no ROI for the hardware companies. Making the drivers doesn't help them sell more hardware. Likewise, the LK devs made these decisions because their vision of the kernel doesn't involve HALs, not to spite FreeBSD.

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 agree with you. We really are a hypocritical bunch. This move may have essentially alienated any new hardware maker from making open source drivers. They too may go the closed source, taped together with a HAL way and that's not good for the long run.

This essentially gives a nod to the way Nvidia's been treating Linux.

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

#209

Post by _yosefk »

sangnoir wrote: post #184
StRoy wrote: post #171

Earlier quoted context omitted.

Without any conflict, uh? https://www.youtube.com/watch?v=iYWzMvlj2RQ > Nvidia has been the single worst company we've ever dealt with. > - Linus Kernel devs are antagonizing the only two GPU makers that matters. Besides the kernel, there has been some flame going between NVIDIA and Wayland devs too. Open source devs are immature men who do not understand the word compromise.

> Without any conflict, uh? > Nvidia has been the single worst company we've ever dealt with. > - Linus This had nothing to do with the kernel and everything to do with the lack of optimus support (years later, its still shit). > Kernel devs are antagonizing the only two GPU makers that matters Maybe the 2 should ask Intel for some pointers on how to contribute to the kernel the right way. > Open source devs are imma…

Sarah Sharp worked for Intel and apparently didn't manage to contribute to the kernel in a way that would make communication with Torvalds particularly pleasant.

I extend my sympathy to anyone paid to contribute code to Linux.

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

#210

Post by shakna »

notalaser wrote: post #180
jaredklewis wrote: post #133

Earlier quoted context omitted.

I'm sympathetic to BSD, but that seems like a lot of misplaced blame to me. Companies don't write FreeBSD drivers because there's no ROI for the hardware companies. Making the drivers doesn't help them sell more hardware. Likewise, the LK devs made these decisions because their vision of the kernel doesn't involve HALs, not to spite FreeBSD.

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 certain way, and the coders were forced to build something they knew would be unmergable. And then management chucked a hissy fit.

There's been really good work here, and management has got upset, rather than follow guidelines, or nVidia's example.

It reflects really badly on the company, which is sad considering the space for AMD left by nVidia's Optimus kafuffle.

There is a market for GPUs here, but it does need to show some professionalism, which they (management) haven't.

Post reply on HN