[arch-general] The OpenCL ICD problem

Ionut Biru ibiru at archlinux.org
Thu Jul 7 09:57:42 EDT 2011


Forwarding discussion to arch-general mailing list.

-------- Original Message --------
Subject: The OpenCL ICD problem
Date: Thu, 7 Jul 2011 15:48:52 +0200
From: Vojtěch Král <kral.vojtech at gmail.com>

Hello,
   I'm writing to you because of a problem which has arisen with the
OpenCL Arch packages.
To introduce myself shortly: My name is Vojtech "kralyk" Kral (Czech 
Rep., EU)
and I currently maintain AMD APP SDK (aka amdstream) and Intel OpenCL
SDK in AUR.

I'm sending this to maintainers who maintain involved pkgs.
People that might be also interested are in Cc, please let me know
should you find this mail too spammy/annoying :)

The problem in question is a conflicting file, namely
/usr/lib/libOpenCL.so (and possibly so version symlinks too).
This file is currently provided by these packages (that I know of):
   nvidia-utils [extra],
   lib32-nvidia-utils [multilib],
   amdstream [AUR],
   intel-opencl-sdk [AUR],
   lib32-nvidia-utils-173xx [AUR] and
   lib32-nvidia-utils-beta [AUR].

The thing is this conflict should be resolved so that it would be
possible to install
OpenCL implementations from multiple vendors at the same time on the
same system (as requested by the standard from Khronos)
while still providing this so file to satistfy dependencies for other
either existing pkgs (such as pyopencl) or possible funture ones.
This should be done in compliance with the ICD standard, see
http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt

However, it should hopefully not be that difficult, since most of the
packages already comply to the standard
by providing appropriate *.icd file in /etc/OpenCL/vendors. And those
that don't should be updated accordingly (lib32-nvidia-utils-beta
maybe? Not sure.)
Also, the standard requests the ICD loader - which is in fact usually
the libOpenCL.so library - to be able to enumerate all the ICDs on its
own.

So this so file is pretty much independent on the vendor it is
supplied by, providing the vendor a) follows the standard correctly b)
is sane :-)

Therefore, a sollution might be to simply pick one of available ICD
loaders (a thin one preferably) and make it a dependency for other
pkgs.
I'm not saying this is an optimal sollution, I'm merely leaving it to
your consideration. Feel free to suggest other possibilities.

Let me know what you think...

Best Regards,
Vojtech "kralyk" Kral


More information about the arch-general mailing list