Hacker News new | ask | show | jobs
by aseipp 3482 days ago
> If the kernel development team does not have the manpower for this, they should better think about a way to maintain the kernel that involves less work.

Or, they could have AMD do the work, since apparently they're the ones who didn't listen -- after being told months ago -- that this rejection could happen when they tried to include a HAL with their driver. I think that perfectly works: the kernel developers don't have to "do all that work" involving un-fucking AMD's driver, and AMD instead has to do the work. Sounds good to me.

There's literally 0 point in accepting the code as-is, because everyone would be on the hook for maintenance it in the mean time, while it got un-crappified, and it would make graphics subsystem maintainers life worse. No. Kick it out, make them do it the right way, and when they come back -- they can talk.

This whole thread has got plenty of of entitled whiners and people with a bone-to-pick against Linux, like yourself, bitching,about OSS maintainers not making their own lives harder because you want feel good about your graphics driver. Get over it. Or, get involved -- maybe you could send a few patches to AMD maintainers to clean out some of the crap.

AMD is not being banned from kernel development, but they're going to have to do it right. Just like the other 20-30 companies that regularly contribute upstream to Linux with their money/developers.

In fact, Linux often accepts drivers for hardware that only certain companies have access to and are of no use to anyone else in the general public. Why? Because they played by the rules, meaning the overall maintenance cost to include those drivers becomes far smaller in the long run. The cost of including the AMDGPU driver, as it is now, is astronomically high in comparison.

> The released open source drivers seem to work quite well (as they do on Windows). The problem is that they don't fit the taste of the kernel developers.

No. Let's be clear: the problem is AMD can't listen, and people like you apparently, can't read. That's about all it comes down to. You are free to now whine and complain about how incredibly important this is and how it's definitely worth breaking the rules over and how much it means to you, and I'm sure the kernel developers owe you this feature, or something (after all, developers are just robots with no lives and if they don't work hard enough, they're bad.)

Meanwhile, it will be ignored, Linux will go on (and continue to crush its competitors in the spaces it matters in), and the world will still turn. And maybe in a year from now AMD will actually have something worth merging. In the mean time, Nvidia will continue to dominate them in the compute market. Maybe actually listening 9 months ago would have saved them some time and market share.

1 comments

> In the mean time, Nvidia will continue to dominate them in the compute market. Maybe actually listening 9 months ago would have saved them some time and market share.

NVIDIA is about the furthest thing from a shining example of good behavior in the Linux kernel. By not having open source drivers at all, they're far worse.

(By the way, their closed source driver has a HAL too.)

Yeah, this seems like the kernel devs are making the classic "the perfect is the enemy of the good" mistake.

They're sending the message that AMD would be better off shipping closed source drivers, like Nvidia, because that would save them the headache of trying to get their merely good but not perfect open source drivers into the hands of users via dealing with Kernel politics.

But then again, what else is new.

I don't think there is much difference between blob and such code from the kernel maintainers' point of view. From users' point of view the difference is huge (freedom to tinker / fix bugs), but maintainers need to keep the whole kernel maintainable. Merging such code would be irresponsible.

And no, I don't want just "good" code in kernel I am using. This is not business. Make it maintainable so it can get better (perfect) in the long run. (yes, I know there are places in kernel where code is not even good, let alone perfect, but that's another issue altogether)

The kernel maintainers can choose between continuing with reverse engineering and hacking together their own driver, or starting with the code of AMDs driver and adapting that.

And you really think continuing with the hacky reverse engineering is the better solution?

Since when did writing a driver become the kernel maintainers' problem?

I don't think the AMDGPU driver not being mainlined really affects Linux. On the other hand, AMD will really benefit from it.

> Since when did writing a driver become the kernel maintainers' problem?

Since the kernel maintainers, and other open source contributors wrote drivers?

> I don't think the AMDGPU driver not being mainlined really affects Linux. On the other hand, AMD will really benefit from it.

You remember the days when Linux never would work on any real PC because audio drivers, GPU drivers, everything was missing? Do you want those back?

Having shitty drivers in the kernel isn’t ideal either, just like microkernels vs. monolithic kernels are a tradeoff, but at least cooperating with them in how to get it best into the kernel (AMD rewrote ~100k LOC since the last "Nope" from the maintainers) would be a lot more helpful than this.

The thing is though, if they shipped a driver like Nvidia does, where it's this blob that just wraps its tendrils into what ever systems are needed, that's not the graphics maintainers problem either

It's a net loss for users of AMD hardware (though AMD's hardware on Linux has been a dumpster fire for as long as I can remember) because they have to suffer arguably worse driver support, but that's on AMD for wanting to have their cake and eat it too