Bug#675528: ITP: ocl-icd -- Generic OpenCL ICD Loader
Le 03/06/2012 15:09, Andreas Beckmann a écrit :
> On 2012-06-02 00:38, Vincent Danjean wrote:
>
>> So, is it possible to upload opencl-headers to main instead of
>> contrib?
>
> Package updated and upload requested ...
Thank you very much.
>> This source package will provide two binary pakages:
>> Package: ocl-icd-libopencl1
>> Description: Generic OpenCL ICD Loader
>> OpenCL (Open Computing Language) is a multivendor open standard for
>> general-purpose parallel programming of heterogeneous systems that include
>> CPUs, GPUs and other processors.
>> .
>> This package contains an installable client driver loader (ICD Loader)
>> library that can be used to load any (free or non-free) installable client
>> driver (ICD) for OpenCL. It acts as a demultiplexer so several ICD can
>> be installed and used together.
>
> If that is compatible with all the implementations, couldn't we just
> call it libopencl1? (+Conflicts/Replaces: libopencl1)
libopencl1 is (currently) a virtual package provided by all
ICD Loader implementations, ie two non-free (amd-libopencl1 and
nvidia-libopencl1) and now there will be ocd-icd-libopencl1.
See at the end of this message why I do not thing it would
be a good thing to remove the other implementations (yet).
> And there should be a corresponding libopencl1-dev package, too.
> As that's probably what users need for their OpenCL applications.
In addition to the library itself, ocd-icd software does not
provide anything but the .so symlink for compilation (that why
I added it directly into the ocd-icd-libopencl1 package: I do
not think that distributing a package with only a symlink
would be correct).
Headers for compilation comes from your package (ie opencl-headers).
>> Package: ocl-icd-dev
>> Description: Development files to build a ICD Loader
>> OpenCL (Open Computing Language) is a multivendor open standard for
>> general-purpose parallel programming of heterogeneous systems that include
>> CPUs, GPUs and other processors.
>> .
>> This package provides a header file that allows a OpenCL implementation
>> to build a installable client driver (ICD). With a ICD, an OpenCL
>> implementation can be used by any OpenCL program without the need
>> to link the program to the specific OpenCL implementation.
> Add something like:
> .
> For building OpenCL applications install the libopencl1-dev package
> instead.
if s/libopencl1-dev/opencl-headers/, I agree. And opencl-headers should
probably itself recommends the virtual package "libopencl1"
>> A few word about the context. There exist lots of OpenCL implementations.
>> A OpenCL program can either link to a specific OpenCL implementation
> IIRC there is non of these packaged in Debian
Yes. There are not in good shape enough to be distributed within Debian.
But they improved a lot recently. Before they can really be used, ocl-icd
will allow to test them with any OpenCL binary program.
So, for me, for wheezy, ocl-icd will be interesting for developers
of open-source OpenCL libraries and, for wheezy+1, ocl-icd will also be
useful for free OpenCL applications.
>> or it can link to a standardized libOpenCL library that allows the
>> program to dynamically choose the OpenCL implementation or even to
>> use several OpenCL implementations in the same program. In fact
>> libOpenCL is only a wrapper (more exactly a dispatcher) to
>> OpenCL implementations provided as ICD.
> currently nvidia-libopencl1 [non-free] and amd-libopencl1 [non-free]
> available - eventually these could be phased out in favor of a free one
In my opinion, it is better to keep nvidia-libopencl1 and amd-libopencl1
for now, even if they are non-free. My reasons are:
- ocl-icd is young and there is probably still some bugs
- ocl-icd requires data not freely available (the order of functions
in the structure). For now, it gets them from (non-free)
implementations that have access to this documentation. It will
be easier to improve ocl-icd if non-free implementation are
available as debian package. [This is not a requirement: the
upstream author Brice will try this week the Intel implementation
with a manual installation to see some new entries in the structure
can be found]
- due to the way that ocl-icd get its documentation, it will
sometimes be bellow other non-free implementation. For researchers
in HPC, it is probably useful to be able to get the last version
of the icd loader of AMD or NVidia.
But it would probably interesting to think to this question again
for wheezy+1
Regards,
Vincent
Reply to: