AMD's Massive New DAL Display Driver Is Facing An Uphill Battle

[phoronix]

Phoronix: AMD's Massive New DAL Display Driver Is Facing An Uphill Battle

We weren't the only ones surprised by the massive size of the new AMDGPU DAL display driver. Weighing in at 93k lines of code, upstream Linux graphics developers outside of AMD are also stunned by the size of this code-base for handling display-related functionality with the AMDGPU driver for Tonga / Carrizo / Fiji...

http://www.phoronix.com/scan.php?page=news_item&px=Massive-DAL-Driver-Woes

[shanefagan]

It's not a bad thing really. If there are things that are useful they can be pulled out and any duplicated features removed and integrated back into AMDGPU. Also usually when big code drops like this happen you re-evaluate already written code and sometimes that can uncover new approaches, bugs to be fixed..etc. So while they might have serious trouble getting it in with it's current form it is still a pretty good thing to happen in general and shows that AMD are pretty serious about the new approach they are making.

[Daktyl198]

While it does seem like they're being serious, this could also be a case of laziness. We already know that a big chunk of the code is straight-up copy/pasted from the Catalyst driver. Maybe they didn't want to do the work of re-writing the catalyst interfaces so instead they're trying to push some messy code into the FOSS driver under the flag of "more complete display stuff" to keep Catalyst changes to a minimum.

Somehow I doubt Marek, and the others would allow that though, so idk. Just theories I guess.

[yro84]

Its funny that ive always seen people (especialy devs) complaining about lack of support from video-card manufacturers. Now that we have this freaking support with that crazy addition to kernel (as open source code) we have the same a$$40les complaining about the amount of work it will need..

[nealeu]

They're not a$$holes. As a dev, I think the feedback is entirely justified. Bloat doesn't just add bytes. It also adds future maintenance costs, when a bit reason for open source is to try to reduce maintenance costs. If AMD do as asked, then it will reduce their costs by sharing the maintenance burden on the shared modules.

It's easy to be impatient, but I know ... today being one of them, just how painful it is when the balance of quick-and-dirty delivery vs quality gets you into difficulty

[boffo]

To quote the people that were saying just open Catalyst, it's just not that easy.
To quote bridgman, first you release the code then you bugfix. So I'm pretty sure that they know that there is work to do.

[Pecisk]

Massive patches always cause tension. I think AMD coders are quite aware about big work ahead for them to make this merged. Now they will have to convince others.

[jf33]

In fact, given the copyrights and briefly looking at the code, it looks like a fair amount of this code was ported over from the AMD Catalyst Linux driver.

What copyrights? I thought the AMDGPU code, as part of the linux kernel, is licensed under GPL?

[duby229]

The strange thing is that I remember years ago Brigdman telling us how Catalyst couldn't be open sourced because there would be problems exactly like this. IE the code won't port cleanly to DRM.

EDIT: It is a good thing to get this code "out there" so to speak. Even if it doesn't get adopted in it's current state, it is the right thing to do.

[bridgman]

What copyrights? I thought the AMDGPU code, as part of the linux kernel, is licensed under GPL?

It's actually "GPL plus additional rights", ie X11.

That said, copyright and license are different things, in fact copyright law is what allows enforcement of GPL and other licenses.