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

[pal666]

Not really. If your hypothetical open source champion works closely with our driver teams for all the other platforms that share the code to come up with a solution that fits the Linux kernel *and* works for all the other platforms then it is strictly beneficial. That's what we have to do.

so you have to do it anyway, the only difference is whether upstream kernel will have driver for vega in this decade on in next

[bridgman]

Perhaps "keeps wasting time" is an exaggeration and not the right thing to say, sorry. I simply meant that from reading his email I get the feeling he got offended, that's simply it.

Of course, but the whole "issue" is about people getting offended, nothing more.

What I was going after is that perhaps he should have keep his feelings aside and just work with the other engineers to do whatever it's needed to do to get the support upstream, that is, remove the abstraction layer that is being questioned.

Dave replied to Daniel's email rather than Harry's, and as a consequence thought we were delivering some kind of ultimatum about upstreaming current code. He got a bit PO'ed and responded more colourfully than usual... the people he offended vented back, total investment maybe 2 minutes, everyone felt better, and now they are all back to work.

The important part is not the venting itself but (a) the information that comes along with the venting and (b) the "hey this is really important and if you thought about it you might conclude that things aren't the way you believe" flag that speaking strongly about something brings to the discussion.

Normally this happens face-to-face at conferences but a lot of key people haven't been able to travel recently so instead of arguing these things out in a conference room or a pub it happened on email.

It's good that the code was reduced, but has the HAL been removed?

Changes are being made, but it's a big task that touches a lot of different OSes and driver teams so takes the most calendar time. The other changes were more self-contained and so could be worked on independently.

I agree with this comment here:

https://www.reddit.com/r/linux/comme...iners/db0e0hx/

Pity because the comment is responding to something that didn't happen (which BTW is the root cause of all this drama). What Alex actually said about corporate culture was:

I can respect your technical points and if you kept it to that, I'd be fine with it and we could have a technical discussion starting there. But attacking us or our corporate culture is not cool. I think perhaps you have been in the RH silo for too long. Our corporate culture is not like RH's. Like it or not, we have historically been a windows centric company. We have a few small Linux team that has been engaged with the community for a long time, but the rest of the company has not.

The reddit comment you referenced suggests that Alex was the one "going on about corporate culture", but that is not the reality. Dave's comments were treating AMD as a homogeneous whole; Alex was making the point that we had different teams with different levels of familiarity with upstream development (zero for most teams) and so like it or not there was going to be a learning curve while the new teams came up to speed... so being surprised and offended when a new team didn't get things exactly right the first time was maybe not the right way to operate.

If you follow the full discussion you'll see some alignment of views resulting from Dave & Alex's initial emails.

As I said, "keeps wasting time" was an exaggeration, but at the same time I feel he was expressing some level of frustration, maybe this could have been avoided somehow and do the right thing from the start?

As I said, this whole thing is a misunderstanding in the first place. We *have* been doing the right thing from the start, but Harry's RFC was misinterpreted as an ultimatum to take DC upstream in its current code or not get open source driver support for future chips.

No question that if everyone had taken time to validate what they thought was being said before resonding then none of this would have happened. Dave didn't realize that we were not trying to upstream current code or making any kind of ultimatum, and our folks didn't realize that Dave was venting because of a misunderstanding.

And no, I'm not trying to start any drama, the drama has already started with these discussions as you can see on reddit, hacker news and this forum.

But you are helping the drama to continue by drawing conclusions based on random internet posts & articles then posting rather than going back to the source material and basing your conclusions on that.

What I'm saying is (a) read the RFC, (b) read all the dri-devel emails rather than just the first one or two.

[bridgman]

so you have to do it anyway, the only difference is whether upstream kernel will have driver for vega in this decade on in next

I don't understand that comment at all. Can you explain it please ?

[ihatemichael]

Of course, but the whole "issue" is about people getting offended, nothing more.



Dave replied to Daniel's email rather than Harry's, and as a consequence thought we were delivering some kind of ultimatum about upstreaming current code. He got a bit PO'ed and responded more colourfully than usual... the people he offended vented back, total investment maybe 2 minutes, everyone felt better, and now they are all back to work.

The important part is not the venting itself but (a) the information that comes along with the venting and (b) the "hey this is really important and if you thought about it you might conclude that things aren't the way you believe" flag that speaking strongly about something brings to the discussion.

Normally this happens face-to-face at conferences but a lot of key people haven't been able to travel recently so instead of arguing these things out in a conference room or a pub it happened on email.



Changes are being made, but it's a big task that touches a lot of different OSes and driver teams so takes the most calendar time. The other changes were more self-contained and so could be worked on independently.


Pity because the comment is responding to something that didn't happen (which BTW is the root cause of all this drama). What Alex actually said about corporate culture was:



The reddit comment you referenced suggests that Alex was the one "going on about corporate culture", but that is not the reality. Dave's comments were treating AMD as a homogeneous whole; Alex was making the point that we had different teams with different levels of familiarity with upstream development (zero for most teams) and so like it or not there was going to be a learning curve while the new teams came up to speed... so being surprised and offended when a new team didn't get things exactly right the first time was maybe not the right way to operate.

Understandable. Things make more sense now, thanks. Glad to know things are moving forward too.

If you follow the full discussion you'll see some alignment of views resulting from Dave & Alex's initial emails.



As I said, this whole thing is a misunderstanding in the first place. We *have* been doing the right thing from the start, but Harry's RFC was misinterpreted as an ultimatum to take DC upstream in its current code or not get open source driver support for future chips.

No question that if everyone had taken time to validate what they thought was being said before resonding then none of this would have happened. Dave didn't realize that we were not trying to upstream current code or making any kind of ultimatum, and our folks didn't realize that Dave was venting because of a misunderstanding.

Makes sense. So the whole misunderstanding happened because Dave thought they wanted to merge the code as-is and it was a RFC?

But you are helping the drama to continue by drawing conclusions based on random internet posts & articles then posting rather than going back to the source material and basing your conclusions on that.

What I'm saying is (a) read the RFC, (b) read all the dri-devel emails rather than just the first one or two.

I will, and I'm not trying to help with the drama to continue, but more like to understand what happened and how things are progressing.

Sorry for any misunderstandings.

[ihatemichael]

he can't understand that, he is disoriented idiot

Idiot is the one who can't respond with nothing but ad hominem attacks. You're clearly the winner.

[entropy]

It went something like this:

http://www.highwaygirl.com/archive/000007.html

Mother Russia as close as 12 miles to American soil?
Somebody got to do something about it.

Nice post, John!

[bridgman]

Yep... I imagine there will be a bridge over the strait some time soon...

... with cutting charges on the piers and two big red buttons, one for each side

[Sonadow]

You bumped the wrong post before

If you absolutely need latest shipping version of the kernel (which may be identical to git at times) then you'll probably need to wait for upstreaming. The AMDGPU-PRO focus is on enterprise/LTS distros and workstation/CAD markets, so while we will be closing the gap between bleeding edge and AMDGPU-PRO support over time the mere fact that it runs on a ~2 month release cycle means you won't get #1 that way.

Same with #4 - picking up an AMDGPU-PRO kernel driver only will give you a good chance of working with the libdrm and mesa which shipped in that distro, but no guarantees about being able to make a franken-stack with that kernel driver plus newer libdrm/mesa. The dependency hierarchy doesn't work that way... kernel + drivers usually should be newer than userspace, not older.

The real solution for what you want (if you insist on #1 and #4) is pulling from upstream. For #2 and #3 only we could satisfy that with a subset of DAL/DC functionality as we do for currently shipping parts, but every year the display logic gets more complex and power management becomes a bigger part of display logic expectations so the subset stopped being "simple" a while ago. Practically speaking you want an upstream driver with DAL/DC included, and that's where our focus is rather than than the subset functionality we ship upstream today.

Maybe I'm the one confused here. Let's try again:

- There currently exists an AMDGPU driver in the kernel for Volcanic Islands, Sea Islands and Southern Islands support. This in-kernel AMDGPU driver forms part of the open graphics stack with the xf86-amdgpu ddx driver (which is not required for Wayland), libdrm and Mesa.
- AMDGPU-PRO sits on top of the AMDGPU kernel driver with additional capabilities
- The DC code which was rejected by Dave, where does it currently live? In AMDGPU-PRO, or in a separate kernel tree?
- Without the DC code, how will the current AMDGPU driver in the kernel, working with libdrm and Mesa as part of the overall stack, be affected in the context of points #1 - #4 that I have previously mentioned?

[Ansla]

Ofc, HDMI 1.4 can't handle wqhd@144, I'm using DP1.2.

Well, some users (including myself) have reported about this problem at least with Hawaii and also Tonga, iirc.

Interesting that it works for you with Kaveri, whose DCE is a few iterations older than Hawaii's and Tonga's. Could you tell me which exact kernel version you are using? Are you using radeon or amdgpu for Kaveri?

I used the Kaveri with the radeon driver most of the time, switched to amdgpu in August to test how it behaves and see what I can expect from my planned new card. I was using the latest stable kernel at that time, 4.7.x. The only change I noticed with the switch to amdgpu was the loss of audio over DP and since I could live with that bought the RX 480 in September.

Ever since I got the 480 it took over the main monitor so I didn't check the Kaveri with newer kernel versions. I could plug the monitor back in the Kaveri to check with linux 4.9 if you think it might have regressed for CIK.

[bridgman]

Maybe I'm the one confused here. Let's try again:

- There currently exists an AMDGPU driver in the kernel for Volcanic Islands, Sea Islands and Southern Islands support. This in-kernel AMDGPU driver forms part of the open graphics stack with the xf86-amdgpu ddx driver (which is not required for Wayland), libdrm and Mesa.
- AMDGPU-PRO sits on top of the AMDGPU kernel driver with additional capabilities
- The DC code which was rejected by Dave, where does it currently live? In AMDGPU-PRO, or in a separate kernel tree?
- Without the DC code, how will the current AMDGPU driver in the kernel, working with libdrm and Mesa as part of the overall stack, be affected in the context of points #1 - #4 that I have previously mentioned?

Ahh, I see the disconnect. Your second point is not correct (at least not for the initial stack) although it may be true in the future. The upstream amdgpu kernel driver and (-PRO) driver are in different kernel trees, although the second is generally a superset of the first. There is also an interal upstream-based development tree which includes DAL, which we publish as amd-staging-N.N in agd5f's repo (currently 4.7).

Dave didn't reject the DC code (although he would not have accepted it in its current form either), he repeated earlier feedback that an interface within the code (which happened to have the same name resulting in great confusion) would have to either be removed or substantially changed. The DC code replaces most of the display logic in the upstream kernel driver, so it goes in (actually sits alongside and is called by) the amdgpu kernel driver. The upstream tree does not include DAL/DC, however our internal development trees do.

When we release an AMDGPU-PRO stack, the kernel driver package source includes and uses DAL/DC.

For currently shipping chips, the display code already upstream will meet your #1-4 criteria without DAL/DC. For future chips we are hoping not to have to double-implement display code (in DAL/DC and non-DAL/DC forms) since that is an increasingly big pile of duplicated effort as display hardware becomes more complex.