Announcement

Collapse
No announcement yet.

Open-Source OpenCL Isn't Even Ready For Fedora

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

  • Open-Source OpenCL Isn't Even Ready For Fedora

    Phoronix: Open-Source OpenCL Isn't Even Ready For Fedora

    The open-source OpenCL acceleration within Mesa/Gallium3D isn't even in a good enough state to be accepted in the usually bleeding-edge Fedora Linux distribution...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I have to agree with David Airlie on this one. I've built the Mesa+OpenCL support on Radeon, and libclc needs some packaging work. This was a fork+fix of the upstream libclc project (http://libclc.llvm.org/). The build system for that one is a distributed Makefile with no configure/autoconf system. If someone wanted something to work on, that might be a good candidate.

    Also, it would probably be good to get the Radeon changes pushed upstream, so that the Radeon+OpenCL support wouldn't need a custom copy of the libclc library to build. This is assuming that the changes are appropriate for upstream merging.

    Comment


    • #3
      Is this (libclc) the libcl ICD loader or is it an OpenCL implementation?

      Looking at the source repository it seems to be too big to contain just a bunch of stubs and a code to load the implementation using the icd file. I was not able to build it to test it myself.

      Comment


      • #4
        Originally posted by stativ View Post
        Is this (libclc) the libcl ICD loader or is it an OpenCL implementation?

        Looking at the source repository it seems to be too big to contain just a bunch of stubs and a code to load the implementation using the icd file. I was not able to build it to test it myself.
        It provides a lot of the OpenCL built-in functions (type-conversion/casting, pre-processor macros, math functions, etc). Check out the libclc project page for a summary.

        The big difference between the upstream and tstellar's version is that the upstream version only supports the PTX target (Nvidia), while Tom's version also includes a radeon-compatible target.

        Comment


        • #5
          Using the upstream version of libclc for R600 depends on having the R600 target added to LLVM and Clang, so until that happens I'm not really planning to do much with libclc. In the meantime, my libclc tree is available and should be good enough for people who want to hack the r600g compute code. If someone is interested in writing a proper build system for libclc, I'll gladly add it to my tree, but this isn't something I have time to work on at the moment.

          As for the state of OpenCL on r600g, we have been making good progress. I just pushed a change today that allows you to run OpenCL while the X server is running, without having to be root, and lately I've been working on enabling more code sharing between the 3D and compute sections of the driver.

          I've also started working on an LLVM/OpenCL TODO, so that people who want to help with the driver know what things need to be done. For people that are new to driver development there are a few "easy" tasks that would be a good way to get familiar with the code. The list is not complete, and I'll keep adding more tasks as I think of them.

          Comment


          • #6
            Originally posted by tstellar View Post
            I've also started working on an LLVM/OpenCL TODO, so that people who want to help with the driver know what things need to be done. For people that are new to driver development there are a few "easy" tasks that would be a good way to get familiar with the code. The list is not complete, and I'll keep adding more tasks as I think of them.

            The Clean up AMDGPUUtil.cpp is just a case of moving things around or it requires more (coding skills etc)??

            Comment


            • #7
              Thanks for the TODO list, it does not look all that hard, maybe on my next vacation I can help a bit

              Comment


              • #8
                Originally posted by 89c51 View Post
                The Clean up AMDGPUUtil.cpp is just a case of moving things around or it requires more (coding skills etc)??
                It's mostly just moving things around, but the unused functions need to be deleted and not moved.

                Comment


                • #9
                  I think i ll probably waste your time than do anything useful so better not touch it.

                  Comment


                  • #10
                    Originally posted by 89c51 View Post
                    I think i ll probably waste your time than do anything useful so better not touch it.
                    If you're interested, you should give it a try. It's a great way to learn the code, and I really don't mind answering questions.

                    Comment

                    Working...
                    X