libOpenCL source code available

[Giuseppe Bilotta]

On Fri, May 31, 2013 at 12:02 PM, Vincent Danjean <vdanjean at debian.org> wrote:
>   Hi,
>
> Le 31/05/2013 11:36, Andreas Beckmann a écrit :
>> On 2013-05-31 09:39, Giuseppe Bilotta wrote:
>>> Am I correct in understanding that only condition 1. is the problem?
>>> (In particular, condition 4. would not apply since the binary would be
>>> distributed as in independent package, and not as part of an
>>> implementation.)
>
> For me, 3 is also problematic from Debian

Why would that be problematic? If (1) is removed and replaced with the
possibility to redistribute the (modified) source and relevant binary,
it seems to be that (3) means you have to share your changes with
Khronos and allow them to add them to the official package. Is that a
problem?

> And, if 1 is removed, I do not know how 4 will be rewritten.

I still think that contacting the Khronos Group about this would be a
good move. I could do it, but I think that someone with a more
official position in Debian would be more appropriate. It should be
enough to raise the issue that in the present state the LICENSE does
not allow packaging of the loader in the Debian main repositories,
maybe with some hints about the (minimum amout of) changes that would
be needed to allow its packaging?

[snip]

>   ocl-icd seems a bit more complex that khronos icd because:
> - it includes a part for reverse-engineering the array of functions
> - it has more code to debug or choose with envvar the loading of ICDs
> - it generates most of the code automatically from the OpenCL headers
>   themselves instead of writing explicitly it => the code is more
>   difficult to understand but it requires less work when new OpenCL
>   functions are added.
> Now we have a full access to description of the whole array of functions
> the last point is less interesting. But will Khronos publish the
> sources of the loader of OpenCL 1.3 as soon as it will be available ?

This is possibly another question that could be raised with them.
Maybe stressing the opportunity for interoperability and
implementor-independence could help convince them? No harm in trying,
anyway.

>   More me, all the difficult part of an OpenCL implementation is
> into the ICD itself (and the associated compiler).
>   If ocl-icd does not work on a plateform whereas Khronos implementation
> works, will all currently available info, it should be easy to fix it.

Of course the hard part remains the actual ICD implementation, and
having the Khronos loader will not fix that. But relying on the actual
reference loader, compiled from source, rather than on a proprietary
one or a reverse engineered one still seems like the best option.

--
Giuseppe "Oblomov" Bilotta