AMD Linux Driver Efforts: Not accepted by Kernerl maintainers

[beginner99]

For anyone interested and not yet having seen it on reddit:

https://www.reddit.com/r/programmin...ux_kernel_maintainer_says_no_to_amdgpu_patch/
https://lists.freedesktop.org/archives/dri-devel/2016-December/126516.html

https://www.reddit.com/r/programming/comments/5hhpqm/amd_responds_to_linux_kernel_maintainers/
https://lists.freedesktop.org/archives/dri-devel/2016-December/126684.html


What does this mean? Probably that AMDs efforts for a good linux driver will get canned again.

 

[sandorski]

That forum is a PITA. Can't find the posts you apparently linked.

 

[Piroko]

I think I can understand both sides.

AMD wanted to write a self-contained driver that reuses as much code as possible for all operating systems. The positive side of that is that this would have rapidly accelerated their Linux driver development (since it profits from the Windows development). The negative side is, it will be a large driver with code that is hard to read and with duplicated functions that already are in the Kernel.

The Kernel maintainers want easy to maintain code that shares as many already implemented functions as possible. Though this also means that actual feature development will probably be slow and painful for everyone...

 

[mnewsham]

The Kernel maintainers want easy to maintain code

No, the kernel maintainers want to maintain the status quo for EVERYONE. Just because it's AMD doesn't mean the kernel maintainers should bend over backwards to make it work for them.

AMD were told back 6+ months ago a hardware abstraction layer would NOT be permissible, they were told they needed to fix things, so they went back, cleaned up some of the backend, but kept the mid-layer abstraction present and were told exactly what they were told MONTHS ago. NO HAL ALLOWED.

 

[Piroko]

AMD were told back 6+ months ago a hardware abstraction layer would NOT be permissible, they were told they needed to fix things, so they went back, cleaned up some of the backend, but kept the mid-layer abstraction present and were told exactly what they were told MONTHS ago. NO HAL ALLOWED.

I'm not arguing against that. But those mailing list participants tend to dramatize the situation to support their position. Like Dave said, it's his only lever and he is willing to hold onto it. Alex from AMD does have a valid point, hardware complexity and -features are currently outpacing Linux kernel support somewhat.

 

[Elixer]

From what I gather, AMD's guys have stated that what they require isn't fully supported, or not supported at all, so they made what they need to get full driver support for their cards as quickly as possible.

Kernel guys want a more generic solution, so they want AMD to purpose what needs changing, and then once that is done, they all vote on what needs to be done and it goes in that circle for awhile, then when it is all hashed out they finally add what is needed.

In the meantime, while all that is hashed out, AMD can't support what they want to support in their drivers without the patch, so, distro maintainers can use the patch if they want or not. This wouldn't be a first that there are different kernels for different hardware.

 

[TheRyuu]

AMD would like to unify their driver stacks so it's possible they go the Nvidia route if this stuff doesn't get into the kernel. At least that seems to be where we're headed since this wasn't merged and it may make more sense for them to do if that's the only way that a unified driver stack would be possible (where you have the same situation where you use DKMS to compile the shim stuff). Nvidia already does this with their drivers and it's what allows them to have support for new features and roughly the same time across platforms.

 

[Headfoot]

Anyone who advocated denying their patch should be forever forbidden from ever complaining about AMD's linux support. You can't have it both ways.

 

[Bacon1]

Here is another article about it:

https://lwn.net/SubscriberLink/708891/183d245f6d536bab/

 

[daxzy]

AMD should stop wasting their time upstreaming drivers and go the Nvidia route.

 

[whm1974]

I did a brief search about the RadeonSI FOSS driver, and it seems to have good Linux performance for a lot of games. Why not just use that?

 

[SpaceBeer]

No openCL yet in open drivers (for Blender, Calc, etc.)

 

[whm1974]

No openCL yet in open drivers (for Blender, Calc, etc.)

OK that makes sense if users do need OpenCL. I guess proper Vulkan support will be needed as well in the future. Although I understand that is being work as well.

 

[mnewsham]

performance for a lot of games

Lets be honest, most people using linux aren't looking to play games, they just want good desktop support, video acceleration, etc. Gaming is not high up on the list. Most people who are interested in gaming and use linux full time have resigned themselves to a windows dual boot, or they run their primary GPU through PCIe passthrough to a windows VM and game in there.

They just want the kernel to be kept in a workable state by anyone and AMD trying to come in with a litany AMD specific additions with their proposal is a slap in the face to that.

Dave was right, it might piss some people off, but linux isn't going away because of this, they have been dealing without AMD for years, no reason to bend over for them now.

 

[whm1974]

Lets be honest, most people using linux aren't looking to play games, they just want good desktop support, video acceleration, etc. Gaming is not high up on the list. Most people who are interested in gaming and use linux full time have resigned themselves to a windows dual boot, or they run their primary GPU through PCIe passthrough to a windows VM and game in there.

They just want the kernel to be kept in a workable state by anyone and AMD trying to come in with a litany AMD specific additions with their proposal is a slap in the face to that.

Dave was right, it might piss some people off, but linux isn't going away because of this, they have been dealing without AMD for years, no reason to bend over for them now.

Well I strongly agree with the kernel developers then. As for me, I quite using Windows at all a few years ago and only game on Linux.

 

[daxzy]

They just want the kernel to be kept in a workable state by anyone and AMD trying to come in with a litany AMD specific additions with their proposal is a slap in the face to that.

Dave was right, it might piss some people off, but linux isn't going away because of this, they have been dealing without AMD for years, no reason to bend over for them now.

Oh thats a load of crap. AMD wanted to use a HAL, but kernel maintainers specifically stated no HAL, for very non-technical reasons (IMO). Kernel maintainers stated that a HAL would add extra complexity due to the fact that you'd need resources to maintain the HAL. Which shouldn't really be a problem because I'm sure AMD (or any other hardware vendor) would want to maintain their own HAL themselves anyways.

Getting r/evolutionary stuff upstream is extremely political (think Game of Thrones). Many of the maintainers fall into two categories. They are either ideologues or they serve at their employer's behest (the vast majority are employed by massive corporations who hire them for the purposes of furthering their corporate agenda). Linux definitely won't go away, but the path is increasingly going towards a fractured ecosystem where corporations take the kernel and adds their own paid (and locked down) solutions on top.

 

[mnewsham]

would want to maintain their own HAL themselves anyways.

and that's exactly why I dont want them to allow it, who says AMD doesn't decide in 3 years to stop maintaining the HAL? Do the kernel maintainers now have to clean up after AMD and maintain it forever? Figure out a work-around scrape it entirely? Etc. The point is there is no reason I can think of that the kernel maintainers should have to lower their standards simply because it's AMD and that's what they want.

 

[daxzy]

and that's exactly why I dont want them to allow it, who says AMD doesn't decide in 3 years to stop maintaining the HAL? Do the kernel maintainers now have to clean up after AMD and maintain it forever? Figure out a work-around scrape it entirely? Etc. The point is there is no reason I can think of that the kernel maintainers should have to lower their standards simply because it's AMD and that's what they want.

I don't buy that argument on a technical merit.

Of the upstream drivers, the majority (or dare I say "all") are written and maintained by the vendor of the product. Of those, there are tons of drivers upstream that are NOT being actively maintained due to them being near EOL. You cannot tell me with a straight face that all those upstream drivers have no issues. Yet the kernel maintainers are perfectly happy to let those drivers exist. It is not a question of lowering their standards. It's just another approach at providing drivers.

 

[mnewsham]

I don't buy that argument on a technical merit.

Of the upstream drivers, the majority (or dare I say "all") are written and maintained by the vendor of the product. Of those, there are tons of drivers upstream that are NOT being actively maintained due to them being near EOL. You cannot tell me with a straight face that all those upstream drivers have no issues. Yet the kernel maintainers are perfectly happy to let those drivers exist. It is not a question of lowering their standards. It's just another approach at providing drivers.

And how many of them require HALs to be implemented in the kernel?

 

[daxzy]

And how many of them require HALs to be implemented in the kernel?

None right now, but as someone involved in driver development I will say straight up that a HAL can be a superior technical solution for some driver types.

Like AMD said, they are extremely resource constrained.

Large corporations with an endless pile of cash can do it two ways: either hire third party companies (like Samsung did with Exynos, which ironically is now largely abandoned upstream) or hire a boatload of extra Linux driver developers. Why? Because you likely need to make (and the more time consuming part is validating) an upstream Linux branch, an out of tree branch (for popular distros like RHEL/SLES/Ubuntu, etc), along with your driver developers for other OS's (VM-Ware, Windows, MacOS). IMO, having a no HAL policy is a political decision to perpetuate the need for a boatload of Linux software engineers. Which, I suppose is the goal of the Linux Foundation, to promote Linux.

I'm sure at some point Nvidia (sitting on their large cash pile) looked at the possibility of upstreaming GeForce support, and said fvk it, not worth the money to pick apart shared (Windows/Linux) code to determine what goes upstream or not.

That said, I think AMD laughably thought that having functional drivers (for the good of end-users, I might add) and technical merit was more important than Linux ideology. The best hope at this point is to go to Valve/Canonical and have it in SteamOS or Ubuntu; since I would imagine the vast majority of Linux gamers would use those.

 

[poofyhairguy]

The best hope at this point is to go to Valve/Canonical and have it in SteamOS or Ubuntu; since I would imagine the vast majority of Linux gamers would use those.

This right here is why I don't care at all about this political battle despite wanting to use Linux with modern AMD hardware. Ubuntu (or distros based on it) is basically THE Linux desktop for consumer user, and their decision to remove compatiblity with the fully closed source AMD driver almost forces them to work with AMD to make sure future releases have as much support as possible. It wouldn't be the first time Ubuntu supported drivers the mainline kernel doesn't support.

I care more about getting the VP9 and HDR support of the ReLive driver in the open source driver than having the open source driver in the mainline kernel. As a user good enough is good enough and for the most part that has been Ubuntu's philosophy too.

 

[mnewsham]

None right now, but as someone involved in driver development I will say straight up that a HAL can be a superior technical solution for some driver types.

Like AMD said, they are extremely resource constrained.

Large corporations with an endless pile of cash can do it two ways: either hire third party companies (like Samsung did with Exynos, which ironically is now largely abandoned upstream) or hire a boatload of extra Linux driver developers. Why? Because you likely need to make (and the more time consuming part is validating) an upstream Linux branch, an out of tree branch (for popular distros like RHEL/SLES/Ubuntu, etc), along with your driver developers for other OS's (VM-Ware, Windows, MacOS). IMO, having a no HAL policy is a political decision to perpetuate the need for a boatload of Linux software engineers. Which, I suppose is the goal of the Linux Foundation, to promote Linux.

I'm sure at some point Nvidia (sitting on their large cash pile) looked at the possibility of upstreaming GeForce support, and said fvk it, not worth the money to pick apart shared (Windows/Linux) code to determine what goes upstream or not.

That said, I think AMD laughably thought that having functional drivers (for the good of end-users, I might add) and technical merit was more important than Linux ideology. The best hope at this point is to go to Valve/Canonical and have it in SteamOS or Ubuntu; since I would imagine the vast majority of Linux gamers would use those.

I still feel like there are more concerns than just the HAL anyway. As stated in the exchange.

The kernel is bigger than any of us and has standards about what is acceptable. Read up on the whole mac8021 problems we had years ago, where every wireless vendor wrote their own 80211 layer inside their driver, there was a lot of time spent creating a central 80211 before any of those drivers were suitable for merge, well we've spent our time creating a central modesetting infrastructure, bypassing it is taking a driver in totally the wrong direction.

I've also wondered if the DC code is ready for being part of the kernel anyways, what happens if I merge this, and some external contributor rewrites 50% of it and removes a bunch of stuff that the kernel doesn't need. By any kernel standards I'll merge that sort of change over your heads if Alex doesn't, it might mean you have to rewrite a chunk of your internal validation code, or some other interactions, but those won't be reasons to block the changes from my POV. I'd like some serious introspection on your team's part on how you got into this situation and how even if I was feeling like merging this (which I'm not) how you'd actually deal with being part of the Linux kernel and not hiding in nicely framed orgchart silo behind a HAL.

Some very valid concerns, if someone comes along and re-writes the AMD code in a smaller more efficient way, but totally messes with AMDs internal development work, does AMD get to go over the random contributor because they're AMD and it's "their" code? Or do we allow linux development to continue as it always has and go with the best code?

It's not JUST there being no HALs

 

[daxzy]

I still feel like there are more concerns than just the HAL anyway. As stated in the exchange.

Some very valid concerns, if someone comes along and re-writes the AMD code in a smaller more efficient way, but totally messes with AMDs internal development work, does AMD get to go over the random contributor because they're AMD and it's "their" code?

It's not JUST there being no HALs

Again, if you re-read these arguments, almost none of it is arguing technical merit.

The passage you just linked is an edge case that I can't even fathom to come to fruition. How the fvck would someone actually rewrite AMD code (and maintain all its driver level functionality) but somehow break the HAL? Or is the argument that let's just refactor the HAL for fvck's sake and not care about the functional driver aspect?

Or do we allow linux development to continue as it always has and go with the best code?

Bwahaha... It certainly does away with BAD code, but to say the kernel always gets the best/optimal code is just being overly gratuitous.

 

[Piroko]

... let's just refactor the HAL for fvck's sake and not care about the functional driver aspect?

The cynical part of me expects exactly this.