[Pkg-opencl-devel] Alternatives system for libOpenCL?

[Vincent Danjean]

Le 27/07/2016 à 10:38, Giuseppe Bilotta a écrit :
> On Mon, Jul 25, 2016 at 2:53 PM, Vincent Danjean <vdanjean.ml at free.fr> wrote:
>>   So, I'm very dubious about introducing a fragile setup (be it
>> alternatives or diversion) in Debian, just to workaround a very
>> buggy external package.
> 
> OTOH, it would seem that Intel has —in its own way— done the “least
> aggressive” thing they could do to allow installation of their
> libOpenCL alongside any existing system installation.

They could have split the ICD loader and the ICD itself. There is
absolutely no need for them to be linked together.
  Unless the changed, their ICD loader (ie the libOpenCL.so)
is a build of the sources available on Khronos GitHub group (perhaps
with a few patches, for example to add versioned symbols).
In any case, their loader seems to be able to run any other ICD
and other loaders (AMD one, ocl-icd one, ...) are able to run their
ICD.
  Really, the ICD loader is really a small peace of code that is
mainly a function dispatcher that look at a functions table provided
by the ICD. One is required to run any available ICD but there are
no performance implication. The only requirement is that the ICD loader
support at least the OpenCL version provided by the ICD (else the new
functions wont be useable).


> Building the
> system libraries with an alternative system already in place would
> allow Intel to repackage theirs following what the system (Debian and
> by derivation Ubuntu) would offer. Of course, the question remains of
> whether they would do it. A safer alternative would be to provide a
> Debian package (even if just a download wrapper) to manipulate the
> Intel-provided rpms appropriately.

If Intel had fixed their licensing info (as one of their guys said to
me a long time ago in a forum) allowing to redistribute their software,
then their ICD (and ICD loader) could be correctly packaged in non-free
(as AMD and NVidia ones).

> (That being said, I still think that offering an alternative system
> would be useful. I know that at least myself would benefit from it,
> since now and again I've had the need to test my clinfo against
> different ICD loaders, and having to switch by
> installation/deinstallation is rather annoying.)

You can put the various libOpenCL.so.1 in different (local) directories
and play with LD_LIBRARY_PATH to choose the one you want to use.
This can even be done without root access (but to setup the used ICD in
the default hardcoded path /etc/OpenCL/vendors if the ICD loader do not
allow to choose another config path).

> Actually, the SONAME was not bumped:
> 
> $ objdump -p /opt/intel/opencl/lib64/libOpenCL.so.2.0 | grep SONAME
> SONAME libOpenCL.so.1

Great.

> but the name of the actual file was.

Ok. It is a bit strange that the name of the library do not start by its
soname, but there are no problems to do so.

> A quick comparison with the OCL
> ICD loader as shipped in Debian unstable only shows an extra
> dependency on libpthread,

I doubt that the Intel ICD loader use pthread itself. It is probably
due to a (unneeded) linker flag.

> and no dependency on ld-linux-x86-64.so

Here, is is probably a libtool artifact in the ocl-icd package. I do not
know if this is the right thing to do or not, but I do not think this has
any consequences.

  Regards,
    Vincent