libOpenCL source code available

[Vincent Danjean]

  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
And, if 1 is removed, I do not know how 4 will be rewritten.

> I don't know how to properly balance licence-wise between allowing
> making packaging changes (e.g. fix typos, add multiarch search paths)
> and restricting changes to the standard (e.g. sort
> KHRicdVendorDispatchRec alphabetically) while calling it still
> libOpenCL.* (there could also be khronos approved patches adding new
> functionality ... probably originating from a vendor)

You know, the code of this library is really simple. It is just
a loader of other libraries and then a dispatcher based on a
array of functions.
There is a few things to take care (error code when there is a
problem, ...) and we should try to stick to the norm and/or
to the Khronos implementation (yes, I run into a problem where
the kronos implementation do not follow the norm...)
  Access to Khronos sources for reading is a good thing. Not because
we need the code itself (again, it is really simple code), but because
we can easily read the specif of their implementation (looking at their
code) and decide if we want to implement to same feature in ocl-icd.
  Also, having the structure name and the description of all official
vendor extensions allow to be more confident that ocl-icd provides
the good thing. But here again, what is needed is detailed specification
(details of the array of functions for example) and not the code
itself.

  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 ?


  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.

  Regards,
    Vincent

> Andreas
> 


-- 
Vincent Danjean          Adresse: Laboratoire LIG - Bât. INRIA Rhône-Alpes
Téléphone:  +33 4 76 61 55 10            655 avenue de l'Europe
Fax:        +33 4 76 61 52 52            Montbonnot Saint Martin
Email: Vincent.Danjean at imag.fr           38334 Saint-Ismier cedex