[arch-dev-public] Bringing libcl 1.2 into Arch
Hello, I've been toying with the idea of bumping libcl from version 1.1 to 1.2. Bellow I will sum up my findings. Current State ------------------- The opencl support is split into three different packages: * opencl-headers - provides header files necessary for compilation, currently at version 1.1 * libcl - provides libCL.so which is an ICD loader, ie. this libraryis used to the actual OpenCL implementation depending on the user needs. In arch we use proprietary libcl from the nVidia drivers. Because nVidia supports only OpenCL 1.1 our library does, too. * opencl-nvidia - an OpenCL implementation. There are packages in AUR that provide the implementation for other vendors, too, such as intel-opencl-sdk There are two main reasons why our OpenCL support is stuck at 1.1: * when the OpenCL support was introduced, libcl was only provided by nVidia and AMD as part of their proprietary drivers, but AMD binary drivers are not supported * nvidia supports only OpenCL 1.1 Proposed Changes ---------------------------- The time has changed and now there are two opensource ICD loaders available: * ocl-icd (https://aur.archlinux.org/packages/ocl-icd/) * opencl-icd (https://aur.archlinux.org/packages/opencl-icd/) Both ICD loaders provide libCL.so in version 1.2. Both ICD loaders are drop-in replacements for the current libcl, ie. no rebuild is needed. I propose the following changes: 1. Update the opencl-headers to 1.2 (again). There is a package opencl-headers12 that grabs them from svn. 2. replace libcl with either ocl-icd or opencl-icd Reasons for change: * replace proprietary libCL.so with an open source one * support for OpenCL 1.2. While nVidia doesn't support this, it will allow using OpenCL 1.2 features on devices that support it (Intel CPU's, AMD GPU's) which couldn't have been used before as they were not provided by libCL Possible Problems --------------------------- So far I was able to find only one possible problem. Applications using OpenCL has to check for the supported OpenCL version on runtime. However, if an application does the check only on compile time, it will crash. IIRC this used to be a problem with luxmark, but I tested it and it works correctly now. I have also tested imagemagick and blender and both work fine. Well, blender is broken for me, but it was before, too. At least it doesn't crash. In more detail, the reason is that you can compile OpenCL 1.2 application without problems even on OpenCL 1.1 system as the libraries and headers will now provide everything needed. However, if the application tries to call an OpenCL 1.2 function, the driver will not provide it, in which case it will crash. In any case if such issue arises, it needs to be fixed upstream. The BIG Question -------------------------- We once had problem that there were no suitable ICD loaders part the one from nVidia. Now we have two. The question is which one to use. * opencl-icd is the reference ICD loader from Khronos. It uses a custom license (or at least a license I don't know) which seems to forbid distributing of sources, but which explicitly allows redistribution of the compiled binaries * ocl-icd is an independent project under 2-clause BSD license. I think from the two this one has longer development Lukas
On 23.05.2014 14:17, Lukas Jirkovsky wrote:
Hello, I've been toying with the idea of bumping libcl from version 1.1 to 1.2. Bellow I will sum up my findings.
Current State ------------------- The opencl support is split into three different packages:
* opencl-headers - provides header files necessary for compilation, currently at version 1.1
* libcl - provides libCL.so which is an ICD loader, ie. this libraryis used to the actual OpenCL implementation depending on the user needs. In arch we use proprietary libcl from the nVidia drivers. Because nVidia supports only OpenCL 1.1 our library does, too.
* opencl-nvidia - an OpenCL implementation. There are packages in AUR that provide the implementation for other vendors, too, such as intel-opencl-sdk
There are two main reasons why our OpenCL support is stuck at 1.1: * when the OpenCL support was introduced, libcl was only provided by nVidia and AMD as part of their proprietary drivers, but AMD binary drivers are not supported * nvidia supports only OpenCL 1.1
Proposed Changes ---------------------------- The time has changed and now there are two opensource ICD loaders available: * ocl-icd (https://aur.archlinux.org/packages/ocl-icd/) * opencl-icd (https://aur.archlinux.org/packages/opencl-icd/) Both ICD loaders provide libCL.so in version 1.2. Both ICD loaders are drop-in replacements for the current libcl, ie. no rebuild is needed.
I propose the following changes: 1. Update the opencl-headers to 1.2 (again). There is a package opencl-headers12 that grabs them from svn. 2. replace libcl with either ocl-icd or opencl-icd
Reasons for change: * replace proprietary libCL.so with an open source one * support for OpenCL 1.2. While nVidia doesn't support this, it will allow using OpenCL 1.2 features on devices that support it (Intel CPU's, AMD GPU's) which couldn't have been used before as they were not provided by libCL
Possible Problems --------------------------- So far I was able to find only one possible problem. Applications using OpenCL has to check for the supported OpenCL version on runtime. However, if an application does the check only on compile time, it will crash. IIRC this used to be a problem with luxmark, but I tested it and it works correctly now. I have also tested imagemagick and blender and both work fine. Well, blender is broken for me, but it was before, too. At least it doesn't crash.
In more detail, the reason is that you can compile OpenCL 1.2 application without problems even on OpenCL 1.1 system as the libraries and headers will now provide everything needed. However, if the application tries to call an OpenCL 1.2 function, the driver will not provide it, in which case it will crash.
In any case if such issue arises, it needs to be fixed upstream.
The BIG Question -------------------------- We once had problem that there were no suitable ICD loaders part the one from nVidia. Now we have two. The question is which one to use.
* opencl-icd is the reference ICD loader from Khronos. It uses a custom license (or at least a license I don't know) which seems to forbid distributing of sources, but which explicitly allows redistribution of the compiled binaries
* ocl-icd is an independent project under 2-clause BSD license. I think from the two this one has longer development
Lukas +1 for the idea.
As for which loader to use, I have no idea. Pick the saner one.
Le vendredi 23 mai 2014, 14:17:25 Lukas Jirkovsky a écrit :
The BIG Question -------------------------- We once had problem that there were no suitable ICD loaders part the one from nVidia. Now we have two. The question is which one to use.
* opencl-icd is the reference ICD loader from Khronos. It uses a custom license (or at least a license I don't know) which seems to forbid distributing of sources, but which explicitly allows redistribution of the compiled binaries
* ocl-icd is an independent project under 2-clause BSD license. I think from the two this one has longer development
Lukas
Tested opencl-mesa with opencl-headers12 and opencl-icd, and it seems to work flawlessly. ++ -- Laurent Carlier
On Fri, May 23, 2014 at 2:17 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
The BIG Question -------------------------- We once had problem that there were no suitable ICD loaders part the one from nVidia. Now we have two. The question is which one to use.
* opencl-icd is the reference ICD loader from Khronos. It uses a custom license (or at least a license I don't know) which seems to forbid distributing of sources, but which explicitly allows redistribution of the compiled binaries
* ocl-icd is an independent project under 2-clause BSD license. I think from the two this one has longer development
Lukas
As there are not many comments regarding the libcl to use, I decided to ask on the ocl-icd upstream whether it can be considered production quality [1]. I would prefer the ocl-icd over the Khronos libCL due to the clearer licensing (BSD license vs. custom license). [1] http://lists.forge.imag.fr/pipermail/ocl-icd-devel/2014-May/000005.html
participants (3)
-
Laurent Carlier
-
Lukas Jirkovsky
-
Sven-Hendrik Haase