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

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

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

    While AMD developers have been working to improve their "DAL" (now known as "DC") display code for the better part of the past year and this code is needed for new hardware support as well as supporting HDMI/DP audio on existing AMDGPU-enabled hardware plus other features, it's still not going to be accepted to the mainline kernel in its current form...

    http://www.phoronix.com/scan.php?pag...DGPU-DC-DRM-No

  • bridgman
    replied
    Nope, just that you have to work the term "pro" into product names somewhere, and preferably some "X"s as well.

    Leave a comment:


  • indepe
    replied
    Originally posted by bridgman View Post
    Agree about amdgpu - the engineering plan was "amdgpu kernel driver", "amdgpu X driver", "amdgpu all-open stack", "amdgpu hybrid stack" (everything fully qualified), but you know the old saying... no plan survives first contact with Marketing.
    So marketing thinks half-closed is professional, and all-open is hobby?

    Leave a comment:


  • bridgman
    replied
    Agree about amdgpu - the engineering plan was "amdgpu kernel driver", "amdgpu X driver", "amdgpu all-open stack", "amdgpu hybrid stack" (everything fully qualified), but you know the old saying... no plan survives first contact with Marketing.

    Leave a comment:


  • andrei_me
    replied
    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

    Leave a comment:


  • automorphism
    replied
    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?

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Tomin
    replied
    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)

    Leave a comment:


  • juno
    replied
    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

    Leave a comment:

Working...
X