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

[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]

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]

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.