Page 1 of 2 12 LastLast
Results 1 to 10 of 12

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,391

    Default 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...

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

  2. #2
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    881

    Default

    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.

  3. #3

    Default

    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.

  4. #4
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    881

    Default

    Quote 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.

  5. #5
    Join Date
    May 2011
    Posts
    37

    Default

    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.

  6. #6
    Join Date
    Jan 2009
    Posts
    1,736

    Default

    Quote 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)??

  7. #7
    Join Date
    Dec 2011
    Posts
    143

    Default

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

  8. #8
    Join Date
    May 2011
    Posts
    37

    Default

    Quote 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.

  9. #9
    Join Date
    Jan 2009
    Posts
    1,736

    Default

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

  10. #10
    Join Date
    May 2011
    Posts
    37

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •