Announcement

Collapse
No announcement yet.

AMD Posts Last KFD Kernel Patches For Discrete GPUs, Needed For Upstream ROCm

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

  • AMD Posts Last KFD Kernel Patches For Discrete GPUs, Needed For Upstream ROCm

    Phoronix: AMD Posts Last KFD Kernel Patches For Discrete GPUs, Needed For Upstream ROCm

    AMD has posted their remaining patches for now for getting the discrete GPU support upstream in the AMDKFD "Kernel Fusion Driver" that is part of their ROCm compute stack...

    http://www.phoronix.com/scan.php?pag...Initialization

  • #2
    My 580 and [email protected] patiently wait.

    Comment


    • #3
      Too bad that next LTS Ubuntu version will ship without it. Another 2.5 years will need to go by before our clusters will see these patches. Just about every repo and experimental features are supported only on LTS releases. I'm not sure upstream kernel usage outweighs actual CodeXL support or any other tool that are only supported on LTS versions.

      Comment


      • #4
        You know HWE Stacks for Ubuntu LTS Releases?

        Comment


        • #5
          oh sweet! running compute without out of tree patches, SOON!

          Comment


          • #6
            Originally posted by Hibbelharry View Post
            You know HWE Stacks for Ubuntu LTS Releases?
            Doesn't matter. AMDGPU-PRO and ROCm 1.7 both require Ubuntu 16.04 LTS kernel (non-HWE stack).

            So if you need OpenCL, you need to use Ubuntu LTS/another supported distro, or ROCm 1.6 (non-dkms package)

            Comment


            • #7
              Originally posted by perpetually high View Post

              Doesn't matter. AMDGPU-PRO and ROCm 1.7 both require Ubuntu 16.04 LTS kernel (non-HWE stack).

              So if you need OpenCL, you need to use Ubuntu LTS/another supported distro, or ROCm 1.6 (non-dkms package)
              The AMD packaged drivers supports the HWE stack.

              Comment


              • #8
                Originally posted by agd5f View Post

                The AMD packaged drivers supports the HWE stack.
                Whaat, is that right? I totally stand corrected then, thanks agd5f Will give it a shot later today.

                Edit: Ahh, I see where my confusion was. 16.04.2 and on comes with HWE already installed (uses kernel 4.10). I was thinking of HWE-edge (uses 4.13 kernel), which I don't believe is supported yet, which makes sense.

                Code:
                $ sudo apt install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04
                Reading package lists... Done
                Building dependency tree      
                Reading state information... Done
                linux-generic-hwe-16.04 is already the newest version (4.10.0.42.44).
                xserver-xorg-hwe-16.04 is already the newest version (1:7.7+16ubuntu3~16.04.1).
                0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
                Code:
                linux-generic-hwe-16.04/xenial-updates,xenial-security,now 4.10.0.42.44 amd64 [installed]
                  Complete Generic Linux kernel and headers
                
                linux-generic-hwe-16.04-edge/xenial-updates,xenial-security 4.13.0.21.27 amd64
                  Complete Generic Linux kernel and headers
                Last edited by perpetually high; 01-05-2018, 01:54 PM.

                Comment


                • #9
                  Originally posted by Meteorhead View Post
                  Too bad that next LTS Ubuntu version will ship without it. Another 2.5 years will need to go by before our clusters will see these patches. Just about every repo and experimental features are supported only on LTS releases. I'm not sure upstream kernel usage outweighs actual CodeXL support or any other tool that are only supported on LTS versions.
                  Don't know if we have explicit plans in place yet, but I think it's worth trying to get the changes backported to the LTS kernel, particularly if it only involves going back one kernel version.

                  Either way, getting the code upstream (at least as far as drm-next) is the critical first step before we can even talk about backporting.
                  Last edited by bridgman; 01-05-2018, 04:10 PM.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    I think it's worth trying to get the changes backported to the LTS kernel
                    That would be amazing. I am very excited for the day that OpenCL also runs fluently without any effort for end users.

                    Comment

                    Working...
                    X