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

[Sonadow]

Zen is just a CPU core, and initial product releases will be CPU-only (various peripherals but no graphics), so no DAL/DC dependency.

We are bringing all future products up on DAL/DC (including the first Zen-based APUs) and I expect we will have DAL/DC upstream before they launch.

The main risk at the moment is getting display support upstream in time to intersect with the spring distro releases; if we miss that then we will need to provide all-open stacks using an AMDGPU-PRO-type DKMS package for the kernel driver install in order to provide user-friendly support for new HW on an already-shipped distro.

Oh, does that mean that the initial launch for Zen will be processor-only and no iGPU cores?

[bridgman]

What does this mean for DP MST support for existing cards? I have a R9 380 and I'm currently using the fglrx driver (patched to support newer kernels) because the AMDGPU driver does not seem to support this feature yet in anything other than mirrored mode for the monitors connected to the DP MST hub, unless I'm doing it wrong somehow. With fglrx it "just works" and sees all of the monitors in amdcccle. Harry's DAL post on dri-devel in February indicated that DAL would allow support for up to six displays in any configuration, including DP MST. Will we have to wait until DAL/DC is mainlined for this to be supported or is it something that will be supported before then in some form? I'm not sure if AMDGPU-PRO supports this yet since I don't use Ubuntu or RHEL.

Thank you to AMD for supporting open source drivers.

AFAIK MST support is fairly limited in the upstream stack today, although my understanding is that the AMDGPU-PRO stack has better support due to use of DAL/DC.

Depending on what kernel version your distro requires, you could try installing a kernel built from agd5f's amd-staging-4.7 branch - barring version compatibility problems that should give you DAL/DC plus all-open stack. Main downside is that it is a development branch rather than a release branch so quality may go up and down a bit depending on the day you sample it.

[bridgman]

Zen is just a CPU core, and initial product releases will be CPU-only (various peripherals but no graphics), so no DAL/DC dependency.

We are bringing all future products up on DAL/DC (including the first Zen-based APUs) and I expect we will have DAL/DC upstream before they launch.

The main risk at the moment is getting display support upstream in time to intersect with the spring distro releases; if we miss that then we will need to provide all-open stacks using an AMDGPU-PRO-type DKMS package for the kernel driver install in order to provide user-friendly support for new HW on an already-shipped distro.

[Sonadow]

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.

Thanks, this clears up most of the confusion I had.

Just one last question: your last paragraph mentioned that amdgpu (the in-kernel version) will do all that i've have asked about, and that future hardware should not have to require such duplication of effort from your side. What effect will this have on Zen hardware on release? Will AMD still have to duplicate effort to get Zen and immediate future hardware working with criteria #1 - #4 on the open stack, or will it decide to simply drop that effort and ask people to use AMDGPU-Pro until the DC code is in a state acceptable for merging upstream?

[automorphism]

What does this mean for DP MST support for existing cards? I have a R9 380 and I'm currently using the fglrx driver (patched to support newer kernels) because the AMDGPU driver does not seem to support this feature yet in anything other than mirrored mode for the monitors connected to the DP MST hub, unless I'm doing it wrong somehow. With fglrx it "just works" and sees all of the monitors in amdcccle. Harry's DAL post on dri-devel in February indicated that DAL would allow support for up to six displays in any configuration, including DP MST. Will we have to wait until DAL/DC is mainlined for this to be supported or is it something that will be supported before then in some form? I'm not sure if AMDGPU-PRO supports this yet since I don't use Ubuntu or RHEL.

Thank you to AMD for supporting open source drivers.

[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.

[Ansla]

Ofc, HDMI 1.4 can't handle [email protected], 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.

[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?

[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

[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!