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

[dungeon]

Does this mean HDMI, DP, FreeSync and all the fancy stuff Michael listed doesn't work for those using the open source AMD driver? And that it all works for those using Catalyst (or whatever AMD renamed their closed source drivers to)?

Problem are those two generalized questions and those are kind of hard to impossible to answer especially for Linux... so general answer should be: for both drivers some of those features might work with driver from git and somewhere it is just not supported.

But in whole, it is totally different from what average AMD user have on Windows... But that is not AMD specific, Linux can be full of surprises if your expectations are set too much high

Let say it simple - it is jungle... now you know it So if you are Tarzan, things there are natural and you can probably survive

[Guest]

What is so wrong with HAL? I would like to know the reason of: "No HALs. We don't do HALs in the kernel."

[scorp]

I am user of AMD GFX since years and I always supported them in good and bad times for trying to do FOSS. However, I'd really like to thank David for doing his great job and keeping the kernel code clean. I am software developer myself and I know very well what it means in long term to integrate some crap into a code base. Where would linux be today from stability and security point of view if people like David wouldn't protect it from corruption by such things like this DAL? It is indeed very unfortunate, that AMD doesn't have enough resources to do it right, but pushing the effort in direction of kernel is not right. I bought RX470 and I'm quite happy with that, I'm using on-board audio through good old 3.5" jack and I can wait until better solution, than pushing crap into the kernel, is ready. If someone doesn't care about quality of linux but is only interested in feature richness at any cost, why are you using linux anyway? Think about it...

[kmare]

Now does AMD really benefit from all their OS efforts? I can only see them reassigning their resourses to proprietary driver or windows development. TBH I do not see how even I would benefit of them being open instead of going the NV way.

Personally I believe that AMD can only benefit from the OS efforts. I'm considering switching to full AMD as soon as I can have everything I need for my professional needs (3D graphics development). That applies to my team as well. I'm pretty sure we're not the only ones. For us right now, the only realistic solution is using Nvidia with the binary drivers for compatibility, stability and acceptable performance. But of course, the issues with having a binary driver are well known in the linux / opensource world.

[newwen]

I wish the DAL code would be accepted in its current form, under condition of providing a roadmap to progressively remove the abstraction layer. I think a compromise should be reached here by all parties.

[iznogood]

Why not add this to staging and see how it works out? If things go wrong they can always drop it from mainline.

Btw I agree with Dave. AMD is a huge company, they make profit from Linux and surely they can hire one or two people to work on this.

Didn't they say in the past that hundred of devs are working on the windows driver? How hard is to expand an open source team of less than ten devs?

[indepe]

Just curious, what did I say to make you think I believed that a solution is "around the corner" ? If anything I have been saying the opposite, talking about "future code" vs "current" or "recent" code as non-trivially different things.

If you are asking me to pinpoint it, I'd say it's mostly that you are saying your intention is to use it for "upcoming" hardware (HW's email), "when it [DC] is ready", as if that were more or less a non-issue, and as if there was little doubt you'd be meeting those requirements around that time. If that time is far enough in the future, and you really don't expect any difficulty in getting there, then this whole discussion might be moot, however that is perhaps the question which needs to be clarified (speaking in terms of the impression I was getting).

[theghost]

I wish the DAL code would be accepted in its current form, under condition of providing a roadmap to progressively remove the abstraction layer. I think a compromise should be reached here by all parties.

I wouldn't do that. Who guarantees that the code is improved and the abstraction layer is removed? What if it's not removed? At this state a lot of users are using it and will be angry if it's ripped out because it was not improved. As soon as bad code is merged and used it's much harder refactor. It's better to do it right from the start if you have the choice.

[theghost]

Dave is a wannabee driver programmer, vulkan coding proves it. He would rather work in amd, but because his code quality is poor, amd will not hire him and this way he has his revenge.

Flagged your post for your insulting trolling. Even you should comply to a minimum etiquette here. Dave has done nothing wrong.

[Peter Fodrek]

Am I to find out possible reason?
Is there anyone that has problem with repeat of 4.9 kentnel devel cycle in 4.10? Especially when critics come from my friendly Red Hat to AMD that I am fan of?

228 companies (that we know about) supported work on the 4.9 kernel. The most active of those employers were:

Most active 4.9 employers
By changesets
Linaro 1876 11.6%
Intel 1869 11.6%
(Unknown) 1293 8.0%
(Consultant) 1055 6.5%
(None) 924 5.7%
Red Hat 916 5.7%
Google 541 3.3%
Samsung 535 3.3%
AMD 476 2.9%
IBM 401 2.5%
Renesas Electronics 331 2.0%
Huawei Technologies 274 1.7%
Linux Foundation 262 1.6%
Mellanox 237 1.5%
SUSE 233 1.4%
ARM 228 1.4%
Oracle 207 1.3%
Texas Instruments 167 1.0%
BayLibre 146 0.9%
Broadcom 136 0.8%

By lines changed
AMD 105820 11.1%
Red Hat 104492 10.9%
Intel 89456 9.4%
Linaro 75310 7.9%
(Unknown) 45676 4.8%
(None) 34464 3.6%
Nokia 34051 3.6%
Google 31054 3.2%
(Consultant) 28989 3.0%
Samsung 25438 2.7%
Oracle 14425 1.5%
Huawei Technologies 14220 1.5%
IBM 13432 1.4%
Raspberry PI 12816 1.3%
QLogic 12439 1.3%
Mellanox 12284 1.3%
Cavium Networks 11741 1.2%
NXP Semiconductors 11662 1.2%
Cisco 11507 1.2%
Linux Foundation 11182 1.2%