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

[vein]

P.S This thread has highlighted the fact that there is a lot of dumb shits on Phoronix!

True But amusing read through and probably gives Michael a few extra coins for all the views

[vein]

Actually this is more about maintainability than stability - DAL/DC code will be more stable than current native code by virtue of being used earlier and by more people.

There is obviously some overlap area (if/when re-factoring in the core code happens there is greater chance of breakage if the restructuring has to include a vendor-specific HAL) but that work tends to happen outside of core kernel development anyways.

Key issue is long term maintainability and that *is* important.

Good! Keep up the good work but don't forget to rest on your vacation!!

[bridgman]

Yep, I thought Christian (deathsimple) summed it up best - something like "we asked for comments, we got comments, everything is proceeding"

BTW Dave didn't say anything yesterday that had not been said before, he was just more explicit about it. It was the "DC the code" vs "DC the interface" ambiguity that made for good television.

If Dave had said "you can't share code and I'm not accepting any of this code even if you reorganize it" that would have been a Really Bad Thing, but that's not what happened.

[seijikun]

I find it quite amusing how big the span of possible meanings is, that can be interpreted into what David wrote. Because I'm one of those who thought that we are all going to die while zombies are eating our brains at

No HALs. We don't do HALs in the kernel.

While the communication after that suddenly sounded like that of three quarreled brothers talking of each other's problems and solving them together with a huge load of cooperativeness and brother-love despite their loyalty to hostile camps. And everyone lived happily ever after:

---

But what I found quite interesting was, what Daniel mentioned about AMD's mindset regarding work beside anything directly relevant to AMD's interests.
Could you (@bridgman) maybe elaborate a bit about if you think what he mentioned was accurate regarding this matter?
How is the mindset regarding Linux at the management level? Do they see it as wasting money?

[entropy]

Damn, can't find the time to read through almost 200 posts.
Someone able to help out with a summary?

[bridgman]

Damn, can't find the time to read through almost 200 posts.
Someone able to help out with a summary?

It went something like this:

http://www.highwaygirl.com/archive/000007.html

[dungeon]

My questions were quite specific, but I can summarize it down to one question: There is an open source driver from AMD and a closed source driver from AMD, what features does each one have that the other is lacking?

That answer is as useful as an ashtray on a motorcycle. I never asked what "might" work, as I wanted to avoid useless speculations. Both drivers are released and can be tested by those using AMD gfx, making the point moot of guessing what "might" work and not.

Sure, and so can Windows. And Apple computers, and cars, and .. well, pretty much anything. But expectations have little to do with my questions.

I've been able to find out that there are 4 different Linux drivers for AMD cards:

1. Catalyst, obsolete and doesn't work with newer cards, kernels nor X servers
2. AMDGPU, the open source driver from AMD for cards released in 2014 and beyond (HD 7700+)
3. AMDGPU-PRO, closed source variant of AMDGPU
4. ati, radeonsi, xf86-video-ati or radeon (hard to find what it's actually named), the older open source driver for pre HD7700 cards, does not work with newer cards

So you know everything, but why you asking generalized questions then Lets be stright there:

Catalyst while being oboslete does not work with Polaris cards only, but should work with anything GCN else. It is X bound up to the version 1.17, but should work with newer kernels even with current 4.9 after patching.

AMDGPU driver was released first with 4.2 kernel, AFAIK that is released august 30. in year 2015. that is far off of 2014. when it was first mentioned First implemented with GCN 1.1 bring up driver and then else newer, but GCN 1.0 will be released only now with kernel 4.9... so only now it support all GCNs.

AMDGPU and AMDGPU-PRO are the two relevant ones for those buying a new gfx card, hence my curiosity what features the closed source driver provides that aren't implemented in the open source one.

That is generalized question again... PRO has CL, Vulkan, DAL(and some features on top of it this thread talks about), etc...

PRO GL part it is much more stable overal, supports professional chips much better, support compatability profiles, has shader cache, supports threaded GL and a whole lot more.

Opensource drivers were traditionaly simple and generic drivers really, and by design easier to maintain ... but that involved by the time to be more and more usable, competative and that will be continued.

So after 18 months of amdgpu release, it is much better now than it was at beggining - time fix most of the things, you just need to work on it It is not that just couple AMD devs involved in that, but 40+ maybe we are safe to say 50 if Bridgman approve the number

[kmare]

so amd had zero benefit from you and it will stay like that in foreseeable future?

Not really.. my last 2 laptops were AMD, plus bought a few more for family/friends. Why?

[Marc Driftmeyer]

Yep, I thought Christian (deathsimple) summed it up best - something like "we asked for comments, we got comments, everything is proceeding"

BTW Dave didn't say anything yesterday that had not been said before, he was just more explicit about it. It was the "DC the code" vs "DC the interface" ambiguity that made for good television.

If Dave had said "you can't share code and I'm not accepting any of this code even if you reorganize it" that would have been a Really Bad Thing, but that's not what happened.

You can't say it, but having been on the inside of large corporations Dave has a line he is authorized to defend, but when crossed it is real simple, ``Money talks, bs walks,'' and he'll want to keep his job because eventually all those ``corporate'' contributors are the actual life blood of Linux and they'll remove him, however it is decided, and Linus will oblige to it happening. He'll find a new one to manage the line, but he won't bite off the hand that feeds.

[bridgman]

While the communication after that suddenly sounded like that of three quarreled brothers talking of each other's problems and solving them together with a huge load of cooperativeness and brother-love despite their loyalty to hostile camps. And everyone lived happily ever after:

The thing is that the "quarrel" part never happened, at least not as far as the kernel developers were concerned. We're talking about people who have been friends and co-workers (albeit at different companies) for a decade or more.

Communication is always a challenge for geographically separated people working together on big complex code without having ever met each other or having any common management... and it only works as well as it does because over time everyone gets to know each other. Until that happens, a bit of yelling sometimes helps.

Everyone had their chance to vent, everyone tweaked their words a bit to avoid misunderstanding or unintended offence, and everyone carried on.

But what I found quite interesting was, what Daniel mentioned about AMD's mindset regarding work beside anything directly relevant to AMD's interests.
Could you (@bridgman) maybe elaborate a bit about if you think what he mentioned was accurate regarding this matter?
How is the mindset regarding Linux at the management level? Do they see it as wasting money?

Daniel was right (at least w.r.t. the last few years) but it's a resource and money thing not a mindset thing. Remember we are just coming out of a period where we had big layoffs every year just to keep the lights on. We kept putting more resources on Linux every year despite that, which has allowed us to do more every year, but it isn't allowing us to do all the things we want yet.

What we have been doing with any developer time we could spare is starting Linux work much earlier in the HW development cycle than before, with a goal of actually having Linux drivers running first (by sharing code with our diags teams) rather than last as has been the case until now.

Vega was the first chip where we started testing Linux drivers on emulated HW before we had silicon back (in case you were wondering what I have been doing for the last ~8 months). It was just a start, but we are now ready to implement & test Linux in lock-step with other OSes for future generations.

Once we get to that point I expect we should see our Linux development work become at least a bit more efficient (by virtue of working with the HW devs when they actually remember something about the chip we are trying to bring up, and being able to identify HW plans that don't work for Linux or open source), and I believe that will give us an opportunity to start working outside of the driver again.