Announcement

Collapse
No announcement yet.

AMDKFD Code Updated For Linux 4.14, More Changes Being Upstreamed

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

  • AMDKFD Code Updated For Linux 4.14, More Changes Being Upstreamed

    Phoronix: AMDKFD Code Updated For Linux 4.14, More Changes Being Upstreamed

    AMD is upstreaming more of their changes to the AMDKFD HSA kernel driver with Linux 4.14...

    http://www.phoronix.com/scan.php?pag...KFD-Linux-4.14

  • #2
    Out of curiosity, what does KFD stand for? In this context it's probably not Katholische Frauengemeinschaft Deutschlands.

    Comment


    • #3
      Should be of benefit to Bristol Ridge APUs as well seeing as how they are turbo-charged Carrizos. YAY !! BTW...is 4.14 going to be the LTS kernel for Ubuntu 18.04 LTS ?

      Comment


      • #4
        Originally posted by VikingGe View Post
        Out of curiosity, what does KFD stand for? In this context it's probably not Katholische Frauengemeinschaft Deutschlands.
        We started development back when "HSA" was called FSA ("Fusion System Architecture") so KFD was the Kernel FSA Driver, or Kernel Fusion Driver depending on who you talk to. Since then (a) the trademark lawyers concluded that "Fusion" was a bad thing so FSA became HSA, and (b) we introduced our own running-slightly-ahead-of-HSA variant called ROC so arguably we should be renaming it to amdkrd / KRD but it's hard to justify spending time renaming the component every time the marketing name changes.

        So think of it as being in the same category as "the display code formerly known as DAL/DC".
        Last edited by bridgman; 08-21-2017, 06:48 AM.

        Comment


        • #5
          Originally posted by bridgman View Post

          We started development back when "HSA" was called FSA ("Fusion System Architecture") so KFD was the Kernel FSA Driver, or Kernel Fusion Driver depending on who you talk to. Since then (a) the trademark lawyers concluded that "Fusion" was a bad thing so FSA became HSA, and (b) we introduced our own running-slightly-ahead-of-HSA variant called ROC so arguably we should be renaming it to amdkrd / KRD but it's hard to justify spending time renaming the component every time the marketing name changes.

          So think of it as being in the same category as "the display code formerly known as DAL/DC".
          "the display code formerly known as DAL/DC" - When is the album gonna drop?

          Comment


          • #6
            Originally posted by boxie View Post

            "the display code formerly known as DAL/DC" - When is the album gonna drop?
            After the Thunderstruck.

            Comment


            • #7
              It seems, I have a fundamental problem understanding the driver situation. Why is it even necessary to have two kernel drivers (amdgpu and amdkfd) instead of one that allows all APIs like OpenGL, Vulkan, OpenCL ... to run on top of it?
              Last edited by GruenSein; 08-21-2017, 08:26 AM.

              Comment


              • #8
                Originally posted by GruenSein View Post
                It seems, I have a fundamental problem understanding the driver situation. Why is it even necessary to have two kernel drivers (amdgpu and amdkfd) instead of one that allows all APIs like OpenGL, Vulkan, OpenCL ... to run on top of it?
                AMDGPU is basically for graphic operations like OpenGL and Vulkan while AMDKFD is more like a complement driver for certain HSA compute operations for things like OpenCL 2+, they don't substitute each other but work togheter as far as I understand

                Comment


                • #9
                  Right.. we started amdkfd as a separate driver to let the compute part move quickly without destabilizing graphics, but probably will integrate them over time.

                  The big thing is that the drm subsystem treats each GPU as an independent entity (with a separate driver instance) while amdkfd provides a single entry point (/dev/kfd) with access to all GPUs in order to efficiently support a unified virtual address space across all GPUs and easy peer-to-peer addressing from one GPU to others.

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    Right.. we started amdkfd as a separate driver to let the compute part move quickly without destabilizing graphics, but probably will integrate them over time.

                    The big thing is that the drm subsystem treats each GPU as an independent entity (with a separate driver instance) while amdkfd provides a single entry point (/dev/kfd) with access to all GPUs in order to efficiently support a unified virtual address space across all GPUs and easy peer-to-peer addressing from one GPU to others.
                    nice, you know if someone has looked into using HHM for AMD stack? giving AMD cpu division just gave us Threadripper/Epyc monsters that can allocate 1/4 TB RAM(in the future tho) HMM could be very interesting when you need massive amount of data to go through the GPU.

                    I'm not sure tho if KFD already do that or if it can be hooked up with HMM in any case

                    Comment

                    Working...
                    X