Announcement

Collapse
No announcement yet.

AMD RadeonSI Driver Officially Gets Compute Support

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

  • AMD RadeonSI Driver Officially Gets Compute Support

    Phoronix: AMD RadeonSI Driver Officially Gets Compute Support

    AMD's open-source "RadeonSI" Gallium3D driver for the Radeon HD 7000 series graphics cards and newer now has early compute/GPGPU support...

    http://www.phoronix.com/vr.php?view=MTM0NDQ

  • #2
    nice i just got my MSI 7770 all nighter compiling

    Comment


    • #3
      Originally posted by jrch2k8 View Post
      nice i just got my MSI 7770 all nighter compiling
      Shouldn't take that long, unless you have to build LLVM as well.
      (make -j1 for mesa 8 /radeon gallium3d was ~1hr on a 1.6 GHz Neo, IIRC)

      Comment


      • #4
        Originally posted by Ibidem View Post
        Shouldn't take that long, unless you have to build LLVM as well.
        In order to get radeonsi compute support, you need to build LLVM from svn with R600 target. Along with some other things like libclc.

        Comment


        • #5
          Originally posted by chithanh View Post
          In order to get radeonsi compute support, you need to build LLVM from svn with R600 target. Along with some other things like libclc.
          Last I checked, libclc is being dropped for direct NVPTX proper seeing as the present lbclc target with the native OpenCL in Clang is for the Nvidia PTX Target, hence the NVPTX target that is on by default.

          At any rate, with an AMD 8350 and 32GB of RAM LLVM/Clang/libc++/compiler-rt/lldb/clang-extra/test-suite/ and enabling the LLVM and Clang Examples builds in around 10 minutes via make -j9, and that includes inserting the R600 under the Experimental Target CMAKE flag.

          Get that built and I you'll probably be spending the bulk of your time fiddling with Mesa config issues.

          Comment


          • #6
            "The open-source Radeon Gallium3D compute support isn't too good yet, namely implemented through OpenCL"

            Anyone can rephrase it so that I can understand it?

            Comment


            • #7
              Originally posted by Marc Driftmeyer View Post
              Last I checked, libclc is being dropped for direct NVPTX proper seeing as the present lbclc target with the native OpenCL in Clang is for the Nvidia PTX Target, hence the NVPTX target that is on by default.
              Last time I checked mesa's configure said that libclc was required.

              It has a target named "r600--" I think this is needed.
              I tried that one http://llvm.org/svn/llvm-project/libclc/trunk (as opposed to git://people.freedesktop.org/~tstellar/libclc, not sure if it is up to date) (you can look at this patch for configure.py that adds a bit of standard functionality for configure/make but it's badly formatted: http://marc.info/?l=mesa3d-dev&m=135423641422147)

              Mesa at least compiles with --enable-opencl and for some reason is 166 Megabyte smaller than 1 or 2 days ago without --enable-opencl. Let's see if it works.

              Edit: Well, X doesn't start when I have radeon enabled (I have a hybrid one with intel):
              Code:
              X: Threading.cpp:28: bool llvm::llvm_start_multithreaded(): Assertion `!multithreaded_mode && "Already multithreaded!"' failed.
              Last edited by ChrisXY; 04-06-2013, 06:45 AM.

              Comment


              • #8
                How usable is the OpenCL implementation (in terms of API/specification completeness) and performance anyway?

                Comment


                • #9
                  Originally posted by brent View Post
                  How usable is the OpenCL implementation (in terms of API/specification completeness) and performance anyway?
                  The current state of things is summarized here: http://dri.freedesktop.org/wiki/GalliumCompute
                  To my knowledge and according to the article, only a few demos work right now. (No, you can't have bitcoin. Not yours.) That also means that nobody is asking for performance right now.
                  Last edited by chithanh; 04-06-2013, 07:13 AM.

                  Comment


                  • #10
                    Damn. Even many basic features are missing. That doesn't look very promising.

                    Comment


                    • #11
                      Originally posted by brent View Post
                      Damn. Even many basic features are missing. That doesn't look very promising.
                      It's a first stab at the problem, just the fact that they actually were able to run some demos is awesome.

                      we will need to wait some more time to actually get full OpenCL compliance, but at least other developers have a place to start working from when adding features

                      Comment


                      • #12
                        Go OpenCL makes our GPU's more useful.
                        OpenCL should displace CUDA and other things by time.
                        (I'm for competition of these api's because you could find good and bad stuff by taking different approaches then the good stuff gets cross pollinated between api's.)

                        Comment


                        • #13
                          Originally posted by brent View Post
                          Damn. Even many basic features are missing. That doesn't look very promising.
                          Currently, there's a bit of a gap in test coverage in Piglit... If you have OpenCL programming experience, feel free to contribute test cases for Piglit. We can't fix what we don't know is broken

                          The big gaps that I'm aware of in clover and the R600 LLVM back-end right now have to do with support for vload/vstore, and data types that are not int/float. Char/Short/Long are still a work in progress in the LLVM R600 backend. They exist, but seem to be buggy when casting/converting between types. I believe that most of the address space types have been taken care of, but I haven't checked in a while.

                          Libclc is missing quite a few built-in functions that need to be provided. I'd suggest cloning http://cgit.freedesktop.org/~tstellar/libclc and trying to implement any built-in functions that you need that are missing. Currently, the upstream libclc maintainer seems to be somewhat unresponsive, so I've been treating Tom's libclc branch on FD.o as the main repository for now. I've also got a repo at http://cgit.freedesktop.org/~awatry/libclc with a few more built-ins that I've been working on (with the intention of having Tom merge my changes when they're ready).

                          There's still a lot of work to do, but there's several discrete pieces that individual people could work on separately without stepping on each other's toes.

                          Comment

                          Working...
                          X