nvidia-cuda-sdk, ati-stream-sdk/amd-app-sdk[1][bug 257626], intel-opencl-sdk[2] and may be ibm OpenCL runtime[3] provide /usr/lib/libOpenCL.so and opencl headers, so it is good idea to provide a way to install this SDKs at once. So eselect-opencl will be a good solution. not 100% working eselect-opencl already in pentoo overlay, but it doesn't do symlinks to headers, it doesn't support latest versions of amd-app-sdk(fails to do symlinks) [1] http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx [2] http://software.intel.com/en-us/articles/opencl-sdk/ [3] http://www.alphaworks.ibm.com/tech/ocr
I've began working on this. See https://forums.gentoo.org/viewtopic-p-6772852.html
As the comantainer of ati-drivers i'm also interested in this package. Now ati-drivers provides OpenCL libraries and libOpenCL.so can of course conflict with the one from nvidia-drivers (hint: sabayon install both by default). From ati-drivers-11.11 opencl libraries are installed only if built with opencl USE flag
Considering interested parties, can't we merge this with eselect-opengl?
See https://bugs.gentoo.org/show_bug.cgi?id=396033 . Basically all OpenCL implementations can coexist and be available without eselect with icd interface.
(In reply to comment #4) > See https://bugs.gentoo.org/show_bug.cgi?id=396033 . > > Basically all OpenCL implementations can coexist and be available without > eselect with icd interface. freeocl doesn't sound as a solution to me. It is "an implementation of the Open Computing Language 1.1 specifications targeting CPUs" so it is not designed as a wrapper. About ICDs you are right, but the libOpenCL.so file collision between different vendors is always there, but eselecting it is dead easy if all libs are in the same place.
As far as I know any libOpenCL.so* is functionally exactly the same icd wrapper and there is no reason to install more than one. If freeocl lib itself is about 1MB (+cmake +openmp). We can remove everything that's not libOpencl.so* or include/CL and call it libicd oslt. Being opensource it's easy to fix, whenever there is a problem. This can be discussed with upstream, if the icd solution is considered as a viable option to eselect-opencl. Though there are mostly no downsides to eselect-opencl either.
(In reply to comment #6) > As far as I know any libOpenCL.so* is functionally exactly the same icd wrapper > and there is no reason to install more than one. > > If freeocl lib itself is about 1MB (+cmake +openmp). We can remove everything > that's not libOpencl.so* or include/CL and call it libicd oslt. Being > opensource it's easy to fix, whenever there is a problem. This can be discussed > with upstream, if the icd solution is considered as a viable option to > eselect-opencl. It's quite the opposite. Freeocl is yet another provider of libOpenCL.so + CL/headers that carelessly installs itself into /usr creating conflicts and thus PITA for package maintainers. Eselect will allow to sort this mess out. Being able to chose implementation is just a fancy by-product, as you've already mentioned it doesn't really matter which libOpenCL you use. > Though there are mostly no downsides to eselect-opencl either.
*eselect-opencl-1.1.0 (21 Jan 2012) 21 Jan 2012; Kacper Kowalik <xarthisius@gentoo.org> +eselect-opencl-1.1.0.ebuild, +metadata.xml: Initial import
