It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel

[karolherbst]

I wish the DAL code would be accepted in its current form, under condition of providing a roadmap to progressively remove the abstraction layer. I think a compromise should be reached here by all parties.

no, because once it is there, it is there for ever except somebody changes it. so no. Except the code gets removed in 2 release if nothing has changed.

[karolherbst]

Why not add this to staging and see how it works out? If things go wrong they can always drop it from mainline.

Btw I agree with Dave. AMD is a huge company, they make profit from Linux and surely they can hire one or two people to work on this.

Didn't they say in the past that hundred of devs are working on the windows driver? How hard is to expand an open source team of less than ten devs?

because the radeon driver can't depend on staging stuff?

[danvet]

Not directly replying to anyone specifically since there's too much, but I figured some more context on some of the ideas brought up here might be interesting. This is me talking with my community hat on, and with that hat on my overall goal is always to build a strong community so that in the future open source gfx wins everywhere, and everyone can have good drivers with source-code. Anyway:

- "Why not merge through staging?" Staging is a ghetto, separate from the main dri-devel discussions. We've merged a few drivers through staging, it's a pain, and if your goal is to build a strong cross-vendor community and foster good collaboration between different teams to share code and bugfixes and ideas then staging is fail. We've merged about 20 atomic modeset drivers in the past 2 years, non of them went through staging.

- "Typing code twice doesn't make sense, why do you reject this?" Agreed, but there's fundamentally two ways to share code in drivers. One is you add a masive HAL to abstract away the differences between all the places you want your driver to run in. The other is that you build a helper library that programs different parts of your hw, and then you have a (fairly minimal) OS-specific piece of glue that binds it together in a way that's best for each OS. Simplifying things of course here, but the big lesson in Linux device drivers (not just drm) is that HAL is pain, and the little bit of additional unshared code that the helper library code requires gives you massive benefits. Upstream doesn't ask AMD to not share code, it's only the specific code sharing design that DAL implements which isn't good.

- "Why do you expect perfect code before merging?" We don't, I think compard to most other parts in the kernel DRM is rather lenient in accepting good enough code - we know that somewhat bad code today is much more useful than perfect code 2 years down the road, simply because in 2 years no one gives a shit about your outdated gpu any more. But the goal is always to make the community stronger, and like Dave explains in his follow up, merging code that hurts effective collaboration is likely an overall (for the community, not individual vendors) loss and not worth it.

- "Why not fix up post-merge?" Perfectly reasonable plan, and often what we do. See above for why we tend to except not-yet-perfect code rather often. But doing that only makes sense when thing will move forward soon&fast, and for better or worse the DAL team is hidden behind that massive abstraction layer. And I've seen a lot of these, and if there's not massive pressure to fix up th problem it tends to get postponed forever since demidlayering a driver or subsystem is very hard work. We have some midlayer/abstraction layer issues dating back from the first drm drivers 15 years ago in the drm core, and it took over 5 years to clean up that mess. For a grand total of about 10k lines of code. Merging DAL as-is pretty much guarantees it'll never get fixed until the driver is forked once more.

- "Why don't you just talk and reach some sort of agreement?" There's lots of talking going on, it's just that most of it happens in private because things are complicated, and it's never easy to do such big course correction with big projects like AMD's DAL efforts.

- "Why do you open source hippies hate AMD so much?" We don't, everyone wants to get AMD on board with upstream and be able to treat open-source gfx drivers as a first class citizen within AMD (stuff like using it to validate and power-on hardware is what will make the difference between "Linux kinda runs" and "Linux runs as good or better than any other OS"). But doing things the open source way is completely different from how companies tend to do things traditinoally (note: just different, not better or worse!), and if you drag lots of engineers and teams and managers into upstream the learning experience tends to be painful for everyone and take years. We'll all get there eventually, but it's not going to happen in a few days. It's just unfortunate that things are a bit ugly while that's going on, but looking at any other company that tries to do large-scale open-source efforts, especially hw teams, it's the same story, e.g. see what IBM is trying to pull off with open power.

Hope that sheds some more light onto all this and calms everyone down ;-)

[-MacNuke-]

How many of these haters here have programmed and/or maintained a large software project that is used by a large amount of people? Or are you just some "linux users" that are using other peoples work for free?

[oooverclocker]

1. DC would of course land in the Kernel no matter if it will stay DC. It's just a matter of time and who would implement them. The code is already there.

2. I guess that some people take some posts too seriously not even being worth to notice. There are always NV fanboys that jump on bad news seeing their chance to spread a bad mood especially when it's their only time now they can feel superior in open source ways. Which includes stupid insults and spitefulness without reasonable arguments. An article with such a headline is like a second birthday in the year to them - especially looking like it was a final decision to drop DAL/DC as a whole which it's absolutely not.

3. I don't believe at all that AMD would not have the resources to maintain the differences in the code with their future! income. Open sourcing already improved the code and its maintainability and also brings many other benefits that are worth some efforts on the other hand. People who open their code are also usually not left alone.

[spangry]

I'm curious, is AMD senior management 'technically inclined' (i.e. promoted engineers), or are they more your general-purpose MBA types?

Just my speculation, but I'm guessing AMD engineers were well aware this was going to happen, but manglement decided to optimise for (very) short-term profit (over long-term survival). In other words same old, same old.

It's never made sense to me why AMD haven't already 'bet the house' on open-source. Intel seem to understand they are not the market incumbent, hence their strong support for open-source development and standards for the Linux GPU stack. I realise that if you look at a desktop market share chart, Windows looks like the 'big target'. But you ignore Linux at your own peril; it's borrowing from the future to feed the present. As Steven Ballmer (of all people) once said: "Developers, developers, developers!"

[davidbepo]

well blame the idealist airlie for amd cards not having the feautures they should

[StanleyKubrick]

I would say "it's how the kernel development process works". Sometimes there is yelling. This isn't the first time and I'm sure it won't be the last.

Well, it goes to show that developers are not movie lovers. I mean, come on, someone called "Dave" is fighting something called "HAL". Now where did I hear this before...

[Berniyh]

I can understand Dave here, I can understand AMD here.

Pragmatically, this will be merged midterm.
Why? Because if newer chips require it the common distros will start shipping it with their kernels.
And then it's only a matter of time until someone admits that they should just upstream it.

[-MacNuke-]

Don't worry. I am not using Linux.

Thanks for the clarification that you are just a troll...