OpenCL in Debian

[Andreas Beckmann]

On 2011-06-27 15:57, Vincent Hindriksen wrote:
> Hi Andreas,
> 
> Thanks for the information and patience - for me it's still a maze, but
> I'll write all things down I learn so others won't bug you.
> For Gedit I made OpenCL lang-files, but for Gnome things go slightly
> different.
> 
> I have good contact with AMD, so I can easily find that out. For Intel
> and IBM I need to make some calls. I'll start with AMD and try to follow
> the procedures of WNPP.

Sounds promising.

> I will look around in WNPP for the following problem I try to answer. At
> http://www.streamcomputing.eu/blog/2011-06-24/install-opencl-on-debianubuntu-orderly/

> I wrote about a problem: libOpenCL.so is a library that looks als the
> ICDs and then includes the libraries. I think it should be open source,
> as it is simple and should be vendor-independent - will suggest the code
> too and also contact the developer who wrote it.

That is something I would really appreciate. Something similar to what
NVIDIA did with libvdpau - that is just a wrapper that loads an actual
implementation.
So far I worked with both the implementations of libOpenCL by AMD and
NVIDIA. They worked quite well with each others implementation, but not
perfectly (AMD being the winner). Also the libraries were compiled a bit
differently (with/without symbol versioning), so an application linked
(-lOpenCL) against AMDs variant would throw warnings when run against
NVIDIAs variant.

Andreas

PS: Re: your blog entry about library names

Usually a library (lets take libfoobar as an example) comes with three
files:
  libfoobar.so.1.234 (the actual file)
  libfoobar.so.1 -> libfoobar.so.1.234 (symbolic link)
  libfoobar.so -> libfoobar.so.1 (symbolic link)

The libfoobar.so link is only needed at compilation time (when you use
gcc ... -lfoobar), therefore in Debian based systems usually shipped in
a libfoobar-dev package together with the headers.
At compilation/linking a dependency of 'libfoobar.so.1' (this is the
SONAME of the library) is recorded in the application.
When the application is being executed, all the recorded dependency
libraries will be loaded, e.g. libfoobar.so.1
The actual library file name can contain some additional versioning
information, e.g. the next release of libfoobar could use
libfoobar.so.1.567 (with an adjusted libfoobar.so.1 link) while still
being compatible to the current one.
An incompatible change (removal of a function, change of some struct in
the library interface, ... but not just the addition of new function
interfaces) would require a SONAME change.

For more details see e.g.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Unfortunately vendors of proprietary software often don't care about
naming their libraries properly and using appropriate SONAMEs :-(
E.g. libcudart.so.2 does dlopen("libcuda.so") which should better have
been libcuda.so.1 - otherwise this indicates: there will never be a
future update that is not backwards compatible.