Announcement

Collapse
No announcement yet.

AMD Working On Making It Easier To Build & Install Radeon Open Compute (ROCm)

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

  • AMD Working On Making It Easier To Build & Install Radeon Open Compute (ROCm)

    Phoronix: AMD Working On Making It Easier To Build & Install Radeon Open Compute (ROCm)

    Now that Radeon Open Compute 2.0 is shipping with OpenCL 2.0 support and many other improvements around Radeon GPU computing, a new focus by the developers working on ROCm is to make it easier to build and install on more Linux distributions...

    http://www.phoronix.com/scan.php?pag...al-ROC-Install

  • #2
    I just checked on Wiki, turns out OpenCL 2.0 was released in 2013, and we are at 2.2 which was released in May 2017...... with next gen OpenCL merged with Vulkan in 2019.

    Comment


    • #3
      Originally posted by ksec View Post
      I just checked on Wiki, turns out OpenCL 2.0 was released in 2013, and we are at 2.2 which was released in May 2017......
      A LOT of scientific projects still use OpenCl 1.2 (even if with new version there are a lot of interesting features)....

      Comment


      • #4
        This is the "state of the nation" of OpenCl, with new OpenCl 2.2 Maintenance Release (May 2018).
        https://www.iwocl.org/wp-content/upl...il-trevett.pdf
        As you can see, "OpenCL 1.2 remains the widely adopted baseline – slow adoption of 2.X"

        Comment


        • #5
          Chicken - egg problem? When basically only the AMD Windows driver supports it, it surely isn't very attractive for many projects.

          Comment


          • #6
            Hopefully this means Gentoo can more easily package it, without having to unpack packages and manually copying files.

            Comment


            • #7
              Originally posted by aufkrawall View Post
              Chicken - egg problem? When basically only the AMD Windows driver supports it, it surely isn't very attractive for many projects.
              No, it's not a chicken-and-egg problem. It's a vendors-protecting-their-locked-in-user-base problem. Nvidia is the best-known, with their CUDA ecosystem. They have locked their OpenCL version at 1.2 for ages, in order to "encourage" their users to stick with the proprietary CUDA solution. But a bad Apple has also fallen into this basket. Apple has discontinued OpenCL support completely and gone to only supporting Metal, or whatever their marketdroids are calling it now.

              So basically AMD and Intel are the only vendors supporting OpenCL implementations at a higher level than 1.2. Hopefully Intel will stick with OpenCL once they get their new discrete GPU game going. The last thing we need would be yet another proprietary compute framework.

              I should also point out that AMD has been shipping OpenCL 2.0 for a long time now with their closed-source drivers, under Linux and Windows. The news here is the AMD's new ROCm implementation is now supporting CL 2.0 also, not that AMD is just now supporting 2.0.

              Comment


              • #8
                Wake me when AMD works specifically with Debian to get those packages sanitized. When that happens a much wider adoption will commence.

                Comment


                • #9
                  Originally posted by Marc Driftmeyer View Post
                  Wake me when AMD works specifically with Debian to get those packages sanitized.
                  I'm pretty sure we don't use the word "boob" anywhere

                  But yes, now that enough of the KFD functionality is upstream we can start working with distros on including packages for the userspace, and that will definitely help with adoption as you say.
                  Last edited by bridgman; 12-21-2018, 03:44 PM.

                  Comment


                  • #10
                    Originally posted by bridgman View Post

                    I'm pretty sure we don't use the word "boob" anywhere

                    But yes, now that enough of the KFD functionality is upstream we can start working with distros on including packages for the userspace, and that will definitely help with adoption as you say.
                    We hear you. - (open) SUSE scientific super computer (build with AMD) 15 tree...;-)

                    Comment

                    Working...
                    X