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

[computerquip]

so your theory of bad FOSS code in reality: YOUR SHIT CODE IS NOT ACCEPTED TO THE KERNEL...

end of story no more shit code... and THIS IS CONSTRUCTIVE

[c2h5oh]

bridgman There definitely is a disconnect. Reading your posts, Harry's and Dave's messages I have an impression that you and Harry have and still are severely underestimating the amount of pushback there is against an effective extra abstraction layer between HAL and DRM. Anything that is more than a very thin HAL to a standardized common interface got a hard no.

DC seems to be a common HAL for Linux and Windows + OS specific abstraction layer wiring it into DRM and what Dave keeps telling you is that is the opposite of what is acceptable. He even provides your with an example why: it's mac80211 all over again.

My recommendation: get on Skype, Google Hangout or whatever. Something that gives both "sides" more ques than email, because clearly the disconnect is huge.

[computerquip]

In technical aspects political correctness is BULLSHIT!
and to be a Social justice warrior in a technical forum is really nonsense.

It's not political correctness. It's called not being a complete asshole just because you can. You can get the same message across in a more mannered tone. It would be more effective since people are more willing to read something that isn't completely aggressive and near insulting which has no reason for being what it is.

[liam]

In technical aspects political correctness is BULLSHIT!
and to be a Social justice warrior in a technical forum is really nonsense.

Well, I very nearly just double posted what computerquip said, so, I'll skip that part.
.....
......
OK! Here's the rule: if you wouldn't talk to your (priest|parent|prof|$authorityFigureYouRespect) that way then you shouldn't say it to the with whom you're speaking. Obviously this rule can be ignored it the other party isn't being respectful to you.
BTW, why do you think bridgman can decide AMD internal resource allocation and project direction? What evidence do you have that bridgman made these decisions?

Edit:

c2h5oh
You make an excellent suggestion! Why kernel folks are so unwilling to deviate from ml when there are better tools (yes, I read the recent lwn article, and no, it didn't make much of a case, imho) I really don't understand.
15min of the right folks over hangouts (very popular in enterprise, interestingly) would get a lot of this worked out, one way or the other.

[oooverclocker]

I was really looking forward to see these features arriving in the Kernel. And I do agree with AMD - in an economical or practical perspective sharing code is very important and it's OK to try it. Not having these features in the Kernel soon would even be a little desaster for several parties like Valve etc.
But Airlie is absolutely right. We already have these drivers that only work with firmware blobs breaking installation media of distributions not shipping them by default. That's a compromise to get hardware accelerated graphics working. (While I think that there has definitely something to be done to make AMDGPU working rudimentarily without firmware, though not necessarily fast enough to play games).
But the Linux Kernel is the most important software project in the world. If it breaks it would lead to a world crisis. There are quality borders that are more important than the development budget of AMD. It's that simple and we will all have to live with it for our own good. Even if it means in the worst case that FreeSync will always be an exclusive AMDGPU-PRO feature. And even if it sounds rude but it's simply consistent.

[computerquip]

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.

[oooverclocker]

debianxfce You are comparing someone being criticized to break the rules with someone who protects the rules. That's absolutely incomparable.

[bridgman]

It is a hard lesson for you to learn and i told you this in the past that in the F(L)OSS world the commercial bullshit code is not allowed. you just did not listen and you pushed your own theory out of a anti-opensource theorie of F(L)OSS is as bad as commercial code and only with much more effort the code come to FLOSS standard.
I think you are wrong! FLOSS is better from the start one and there is no way to lower this standards to commercial bullshit style code standards.

I have no idea what all the "you did / you pushed / you are wrong" comments mean - when you say "you" do you mean me or AMD in general ?

When you say "I think you are wrong" what statement of ours/mine are you disagreeing with ?

[bridgman]

bridgman There definitely is a disconnect. Reading your posts, Harry's and Dave's messages I have an impression that you and Harry have and still are severely underestimating the amount of pushback there is against an effective extra abstraction layer between HAL and DRM. Anything that is more than a very thin HAL to a standardized common interface got a hard no.

DC seems to be a common HAL for Linux and Windows + OS specific abstraction layer wiring it into DRM and what Dave keeps telling you is that is the opposite of what is acceptable. He even provides your with an example why: it's mac80211 all over again.

My recommendation: get on Skype, Google Hangout or whatever. Something that gives both "sides" more ques than email, because clearly the disconnect is huge.

Did anyone actually READ the RFC ? Harry was proposing precisely one thing for comment - using DC initially for as-yet-unreleased hardware rather than trying to cut over all of the currently supported chips at the same time. He also said that we couldn't publish the "new GPU" code yet but in the meantime we would continue to work away in public on the changes that had been identified in the initial review.

[bridgman]

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.

Actually Dave was the first person I called to ask for advice when I volunteered to set up the open source graphics initiative back in 2007, and you are probably running quite a bit of his code on your system today.

Dave had already accepted an offer from Red Hat by the time we first talked.