Open-Source OpenCL Isn't Even Ready For Fedora

[phoronix]

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

[Veerappan]

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.

[stativ]

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.

[Veerappan]

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.

[tstellar]

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.

[89c51]

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

[geearf]

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

[tstellar]

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.

[89c51]

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

[tstellar]

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.