Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by bridgman View Post

    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?

    Comment


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

      Comment


      • Originally posted by automorphism View Post
        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.

        Comment


        • Originally posted by bridgman View Post
          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?

          Comment


          • Originally posted by Ansla View Post
            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.
            Thanks for the reply.
            I don't think it regressed, more likely never worked for some asics. I'm not 100% sure, though. I already tried older kernels and 4.7.x was definitely among them.
            However, if you happen to discover something of course I'd be glad

            Comment


            • Originally posted by Sonadow View Post
              Oh, does that mean that the initial launch for Zen will be processor-only and no iGPU cores?
              That is what he said.

              Zen is just a CPU core, and initial product releases will be CPU-only (various peripherals but no graphics)

              Comment


              • Originally posted by bridgman View Post

                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.
                Thanks for your reply.

                I am using Gentoo as my primary distro, in part because it allows me to keep Xorg 1.17 so I can run fglrx, while still running modern versions of everything else. So I can use more or less whatever kernel I want and I'm used to compiling it myself. For that matter, it should be possible to replace libdrm and mesa with whatever versions are supported by AMDGPU-PRO to avoid the "franken-stack" scenario you described earlier in the thread.

                I'll test the amd-staging-4.7 kernel when I have some time to mess around with it and see if it works with my configuration. I'll probably also test out AMDGPU-PRO on an Ubuntu install, since if that works well it might be worthwhile trying to get it to work with Gentoo. I'd been expecting DAL/DC to be ready soon, or I would have tried them already. Since it sounds like either the staging kernel or AMDGPU-PRO should be able to see all of my monitors I'll file bug reports if that's not the case.

                That being said, fglrx is working reasonably well for me, with any kernel version up to and including 4.9, so I don't need to switch quite yet if the replacement isn't ready. I was just wondering if DP MST support was something that would or could be mainlined independent of DC/DAL, like the other features that have been added in the meantime, or whether it'll have to wait for the full DC/DAL to be ready.

                Comment


                • I don't think it's practical to mainline the DP/MST support from DAL without also bringing other big chunks of the code along, so it would only be feasible if we concluded that piece-by-piece upstreaming was best (and even then it couldn't be the first piece or anything like that).

                  You may need a newer libdrm from upstream as well, depending on what you have on your system today.

                  Comment


                  • Originally posted by bridgman View Post
                    I don't think it's practical to mainline the DP/MST support from DAL without also bringing other big chunks of the code along, so it would only be feasible if we concluded that piece-by-piece upstreaming was best (and even then it couldn't be the first piece or anything like that).

                    You may need a newer libdrm from upstream as well, depending on what you have on your system today.
                    I'm running the stable branch of Gentoo which is on libdrm 2.70 currently, but I can easily install 2.74 from the testing branch if needed for the staging kernel, or just to experiment and see if it works better. Similarly, I currently have mesa 12.0.1 from stable installed but 13.0.2 is available in testing. I can also install a version in between. Is there a specific version AMD is targeting with the staging kernel, or a minimum version?

                    Comment


                    • bridgman AMD needs to name thing differently to avoid further confusions, we got radeon, radeonsi, amdgpu, amdgpu-pro, DC (whole package), DC (abstraction layer)
                      every now and then a new confusion caused by those names appear

                      Comment

                      Working...
                      X