Accéder au contenu.
Menu Sympa

starpu-devel - Re: [Starpu-devel] SOCL and ICD

Objet : Developers list for StarPU

Archives de la liste

Re: [Starpu-devel] SOCL and ICD


Chronologique Discussions 
  • From: Vincent Danjean <Vincent.Danjean@imag.fr>
  • To: Nathalie Furmento <nathalie.furmento@labri.fr>
  • Cc: starpu-devel@lists.gforge.inria.fr, brice.videau@imag.fr
  • Subject: Re: [Starpu-devel] SOCL and ICD
  • Date: Tue, 02 Oct 2012 20:13:11 +0200
  • List-archive: <http://lists.gforge.inria.fr/pipermail/starpu-devel>
  • List-id: "Developers list. For discussion of new features, code changes, etc." <starpu-devel.lists.gforge.inria.fr>
  • Mailscanner-null-check: 1349806019.82414@LxqZPEP2CmA8QM8gQPZ4uQ

Le 02/10/2012 15:29, Nathalie Furmento a écrit :
> On Oct 02, 15:07, Ludovic Courtès wrote:
>> If that libraries defines specific macros, or exports specific symbols,
>> ‘configure’ could check for them.

A macro is not really useful : ocl-icd installs a library (libOpenCL.so)
and a header (ocl_icd.h).
However, the header provides some info required to compile a ICD but
the header is not useful to compile a program against libOpenCL.so.
The header can be installed and used whatever version of libOpenCL.so
is installed.
So there is no point into adding macro and/or function declaration
into this header.

To compile against libOpenCL.so, only the official Khronos OpenCL
headers are required. Of cause, we cannot (and want not) modify them.
Moreover, the compiled program should be able to run with whatever
libOpenCL.so will be found at runtime.

I had the same problem when adding ICD support in POCL. So I agree
that something must be done. I see several things :
- add a symbol in the library. For example a
char* ocl_icd_version()
Pro : can be used to check the library
Cons : easy to write an OpenCL that wont run with another libOpenCL.so
(if it use unconditionally this symbol)
- add this function (or another) but its address must be obtain
through clGetExtensionFunctionAddress
Pro : same as before
Pro : do not modify the ABI
Cons : not really following the spec

I think the second one is better. What do you think ?

Regards,
Vincent

> That could be a solution.
>
> Nathalie
>


--
Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble
Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot
Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin





Archives gérées par MHonArc 2.6.19+.

Haut de le page