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

While AMD developers have been working to improve their "DAL" (now known as "DC") display code for the better part of the past year and this code is needed for new hardware support as well as supporting HDMI/DP audio on existing AMDGPU-enabled hardware plus other features, it's still not going to be accepted to the mainline kernel in its current form.

This morning I wrote about AMD Seeking Comments On DC/DAL Code, Wants To Land It Soon For Future GPU Support. While being hopeful that it would land soon as it's a blocker for future hardware support and the lack of HDMI/DP audio, among other features can be frustrating to some users, it's now clear that it's not going to be accepted yet.

The Linux kernel's DRM (Direct Rendering Manager) subsystem maintainer David Airlie of Red Hat has flat out rejected it. "No HALs. We don't do HALs in the kernel. We might do midlayers sometimes we try not to do midlayers. In the DRM we don't do either unless the maintainers are asleep. They might be worth the effort for AMD, however for the Linux kernel they don't provide a benefit and make maintaining the code a lot harder...Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code I'll give you one guess where my loyalties lie...I honestly don't think the code is Linux worthy code, and I also really dislike having to spend my Friday morning being negative about it, but hey at least I can have a shower now. No."

He's not accepting this big display code rework for AMDGPU due to the abstractions with AMD trying to share this display code on Windows too. Airlie provided some follow-up comments in this email.

David Airlie also commented in our forums, "And it would be AMD who got thing wrong. We've no idea what the DAL3 team were asked to come up with, but what they didn't come up with was an upstreamable driver, if that was on the goal sheet, it either wasn't far enough up it, or nobody had any idea what it meant."

Thus AMD is put in a rather difficult place. AMD has already said they don't have the resources to maintain a non-DAL/DC stack and that this DC code is necessary for future GPU support. To get accepted into the mainline tree they would need to remove all of the abstractions, which AMD has expressed they are against due to their limited developer resources (less code sharing with Windows) and also all their QA teams working on this DC/DAL code. AMD is free to maintain the code outside of the Linux kernel but will likely not get much traction outside of enthusiasts and dedicated free software gamers. They ship the code already in their AMDGPU-PRO hybrid driver, but outside of professional folks, many enthusiasts/gamers are prefer to refrain from using this hybrid proprietary driver.

Thus with not getting this code mainlined, it threatens the upcoming AMD GPU launch from having any mainline kernel support unless AMD is able to quickly rework it to use the existing AMDGPU display code, but given the massive undertaking, it's a lot of work to get done in a short amount of time when they are already stretched for resources. This is also a setback to anyone hoping to use the mainline AMDGPU kernel driver with HDMI/DP audio, FreeSync, HDMI 2.0, atomic mode-setting, DP MST, and other modern display features.

Will be interesting to see how this situation plays out in the days/weeks ahead; it's a very unfortunate situation for AMD.