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

[Jabberwocky]

1) This would not have been so controversial if people were not expecting the code/features.

2) Just because it is not mainlined does not mean that you can't use it ourself. It does not violate the license of the kernel, so a distribution can ship it.

3) There are rules in place for a reason, I agree with the rules and it's important to respect and adhere to it.

4) It's sad that time is wasted on politics and keeping people happy. David Airlie should be spending his time to code/review not to chat to people, it's not his fault that the code is not acceptable.

5) debianxfce is the worst I have seen this year, my award usually goes to youtube users, it's actually funny and a little bit sad LOL.

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.

[Adarion]

OMG, it's like a fire in a petrol factory. Flames are rising quickly.

Well, why not put the whole thing into staging? I mean, what is staging good for if not that?
Users will benefit from the new features and support.
AMD will be a little less under stress with the limited manpower.
The code is still in staging and can mature over time until it is recognized to meet the "official" quality criteria.

Good?

[juno]

No, HDMI/DP works just fine for video. The problem exists only for audio through HDMI/DP.

I wouldn't call it fine, when people still have issues with 144 Hz WQHD output (unusable), and there is no HDMI2 nor FreeSync

[dungeon]

Ah this gonna 100 so happy 100 comments, see you @ 200

But it is enough i think everybody said already what they want

[Beherit]

Problem are those two generalized questions and those are kind of hard to impossible to answer especially for Linux...

My questions were quite specific, but I can summarize it down to one question: There is an open source driver from AMD and a closed source driver from AMD, what features does each one have that the other is lacking?

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.

That answer is as useful as an ashtray on a motorcycle. I never asked what "might" work, as I wanted to avoid useless speculations. Both drivers are released and can be tested by those using AMD gfx, making the point moot of guessing what "might" work and not.

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

Sure, and so can Windows. And Apple computers, and cars, and .. well, pretty much anything. But expectations have little to do with my questions.

I've been able to find out that there are 4 different Linux drivers for AMD cards:

1. Catalyst, obsolete and doesn't work with newer cards, kernels nor X servers
2. AMDGPU, the open source driver from AMD for cards released in 2014 and beyond (HD 7700+)
3. AMDGPU-PRO, closed source variant of AMDGPU
4. ati, radeonsi, xf86-video-ati or radeon (hard to find what it's actually named), the older open source driver for pre HD7700 cards, does not work with newer cards

AMDGPU and AMDGPU-PRO are the two relevant ones for those buying a new gfx card, hence my curiosity what features the closed source driver provides that aren't implemented in the open source one.

[theghost]

OMG, it's like a fire in a petrol factory. Flames are rising quickly.

Well, why not put the whole thing into staging? I mean, what is staging good for if not that?
Users will benefit from the new features and support.
AMD will be a little less under stress with the limited manpower.
The code is still in staging and can mature over time until it is recognized to meet the "official" quality criteria.

Good?

Already explained by Daniel here: https://www.phoronix.com/forums/foru...917#post916917

[mr_tawan]

I'm kinda understand why this is not accepted. I think it's a legit reason to reject the code when the code is not written in the similar way as the other code in the code base, especially 100k loc changes. Yes it sucks not to be able to use the audio over HDMI/DP soon (I'm using the Rx480 so I'm disappointed as well.), but well that can't be help. Remember when code is merged, it stays there forever. If the maintainers are not confident to have it then they have a right to reject.

I think AMD might have to be work more closely with the kernel maintainers. I think it's also sucks to have that large code changes rejected. Just thought how much of the afford has been put into the code change. BTW I think bridgman mentioned that it's not completely waste, is it ?

[theghost]

I'm kinda understand why this is not accepted. I think it's a legit reason to reject the code when the code is not written in the similar way as the other code in the code base, especially 100k loc changes. Yes it sucks not to be able to use the audio over HDMI/DP soon (I'm using the Rx480 so I'm disappointed as well.), but well that can't be help. Remember when code is merged, it stays there forever. If the maintainers are not confident to have it then they have a right to reject.

I think AMD might have to be work more closely with the kernel maintainers. I think it's also sucks to have that large code changes rejected. Just thought how much of the afford has been put into the code change. BTW I think bridgman mentioned that it's not completely waste, is it ?

No, you can already use it. Just install the AMDGPU-PRO driver.
Most probably AMD will provide it until all features of it are mainlined.

[geearf]

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.

As a non-dev but power user, the ability to bisect is amazing!
Instead of waiting for the devs to look all around their code to see what could fail, you give them the failure right away (ok not always...) which increases the chance of getting a fix, and the speed of that. (Depending on the issue you could also just revert the patch while keeping the rest).

As a dev, well you don't need me to explain
But even in the above case, I've had once a radeonsi patch that didn't work and the dev realized it had a typo and gave me a new patch with... the same content! Thanks to his message and the small patch, I was able to quickly find his typo and try it out myself (no GPU knowledge was needed, really easy stuff), instead of having to wait for him. That saved me time

As a non-dev and non-power user, nothing directly to you, but hopefully through users in above categories you still benefit.

[LasseKongo]

No, you can already use it. Just install the AMDGPU-PRO driver.
Most probably AMD will provide it until all features of it are mainlined.

If you run a specific version of Ubuntu or RHEL, this is a possible workaround, for those of us who don´t it is not an option. Actually the old fglrx driver were more widespread to other distributions than amdgpu-pro.
Really hope this mess can get sorted out so we can finally ditch the proprietary drivers once and for all.