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

[duby229]

So is DAL/DC OK now or are you still upset about something ? If so could you be a bit more specific than "2016" ?

ROCm is already being fixed up as well, although you might be able to beat us with that for a little while longer. It's a big code base developed by a lot of different teams in parallel and getting it all clean and consistent is going to take some work.

I don't see AMDVLK changing since it is by definition an internal multi-API multi-OS project that we sanitize for each release. If you keep getting triggered by that I don't know what to say other than to suggest that there are more important things to get upset about.

There are a few things about DC I still don't like. It's still AMD-only with no possible way to share it's features with other drivers that have similar requirements. Sharing infrastructure is kind of a big point of open source and DC is the antithesis of that. I hate it, not for what it is, but for what it isn't. It might be open source, but it in no way meets the ideals of open source.

It -NEVER- should have been accepted upstream until it became a cross-vendor agnostic infrastructure any driver could use for it's features. It's the same reason why amdkfd -never- should have been accepted upstream. Amdkfd is even worse for this reason than DC is.

[bridgman]

Most of ROCm has no such chance to ever get fixed up and none of amdvlk has that chance at all. I mean, I did already mention both ROCm and amdvlk... Is ROCm recent enough for you? How about amdvlk?

So is DAL/DC OK now or are you still upset about something ? If so could you be a bit more specific than "2016" ?

ROCm is already being fixed up as well, although you might be able to beat us with that for a little while longer. It's a big code base developed by a lot of different teams in parallel and getting it all clean and consistent is going to take some work.

I don't see AMDVLK changing since it is by definition an internal multi-API multi-OS project that we sanitize for each release. If you keep getting triggered by that I don't know what to say other than to suggest that there are more important things to get upset about.

[duby229]

Sorry if I wasn't clear - the point I was making was that your proof of "years of the same behaviour" was issues in 2016 around the initial DAL/DC RFC rather than anything recent. What similar issues are you seeing with DAL/DC in 2020 or 2021 ?

DAL was lucky, imo... It had been submitted to the linux kernel after all, it got (sorta) fixed up after years of effort. (Which was predicted at that mailing list thread I pulled those two posts from btw...)

Most of ROCm has no such chance to ever get fixed up and none of amdvlk has that chance at all. I mean, I did already mention both ROCm and amdvlk... Is ROCm recent enough for you? How about amdvlk?

Closing your eyes and saying "la la la la la la" doesn't make DAL or ROCm or amdvlk any better... (Thank goodness for real community based OSS efforts like radv and aco and clover. At least they get developed in public according to upstream specifications with comprehendable coding styles)

[bridgman]

Sorry if I wasn't clear - the point I was making was that your proof of "years of the same behaviour" was issues in 2016 around the initial DAL/DC RFC rather than anything recent. What similar issues are you seeing with DAL/DC in 2020 or 2021 ?

[duby229]

If you had to use examples from 2016 to establish "a clear pattern... to this very day" then with respect it may not be as clear as you think. The DAL team largely works directly in upstream these days, as do most of the lower level ROCm components.

AMDVLK is still "throw it over the wall", unfortunately, however that seems to be a necessary consequence of using the same code base for multiple APIs and having to strip out big chunks of 3rd party IP on every release leaving only Linux/Vulkan.

2016 thru 2021 is years of the same behavior, that -is- a clear pattern. You can try to excuse it all you want but then it's just excuses...

[bridgman]

If you had to use examples from 2016 to establish "a clear pattern... to this very day" then with respect it may not be as clear as you think. The DAL team largely works directly in upstream these days, as do most of the lower level ROCm components.

AMDVLK is still "throw it over the wall", unfortunately, however that seems to be a necessary consequence of using the same code base for multiple APIs and having to strip out big chunks of 3rd party IP on every release leaving only Linux/Vulkan.

[duby229]

So just looping back here a bit - one of the big challenges with the DC rollout was that at the time the Linux drivers had moved to an IP-block-centric model (which aligned nicely with the "shared helper functions called by OS-specific code" model that Dave and Daniel preferred) but the Windows drivers had not... and the DC code had to support both drivers although it was developed for Linux first.

A couple of years ago the Windows drivers switched over to the same IP-block-centric model (around RDNA1 time IIRC) so if we were to launch DC today rather than four years ago it probably would have gone a lot more smoothly.

I'm not convinced. If that first revision of DAL was released today, it still would have been completely rewritten multiple times just to make it understandable. It had layer upon layer of abstraction that made it unintelligible. Which is still a problem with every single new code "dump" that AMD makes even up to this very day. The problem is still the same and I don't think it would make a single bit of difference.

AMD still lives inside it's walled garden and throws code over without consideration at all for upstream communities. In fact it seems pretty obvious AMD doesn't care at all about upstream communities and avoids them at any cost or simply ignores them when they can't avoid them. ROCm, amdvlk and DAL are all absolute proofs of this in my opinion.

EDIT: Most of the issues that Dave (and almost all others) had with DC are still issues AMD has with every single code dump they release even to this very day... That second link is particularly close to my own opinion... It's a perfect example of AMD valuing their walled garden above and beyond the upstream community by completely ignoring them. DAL isn't the last example of this, it's become a clear pattern.

https://lists.freedesktop.org/archiv...ry/100566.html
https://lists.freedesktop.org/archiv...ry/100569.html

[f0rmat]

Nope, just that you have to work the term "pro" into product names somewhere, and preferably some "X"s as well.

How about "pro x all-opensource hybrid kernel amdgpu dc color-fish driver." That should hit all the buttons for marketing, although it might be a PITA to type in a CLI.

[bridgman]

So just looping back here a bit - one of the big challenges with the DC rollout was that at the time the Linux drivers had moved to an IP-block-centric model (which aligned nicely with the "shared helper functions called by OS-specific code" model that Dave and Daniel preferred) but the Windows drivers had not... and the DC code had to support both drivers although it was developed for Linux first.

A couple of years ago the Windows drivers switched over to the same IP-block-centric model (around RDNA1 time IIRC) so if we were to launch DC today rather than four years ago it probably would have gone a lot more smoothly.

[bridgman]

Nope, just that you have to work the term "pro" into product names somewhere, and preferably some "X"s as well.