Hi,
Nice summary. Just few comments below
Le 03/09/2012 07:59, Kalle Raiskila a écrit :
> Lets see if I can summarize this up:
>
> 1. Most users ("all"[sic]) will want to use the ICD, as this seems to
> become the de-facto on desktops.
>
> 2. The possibility to link directly, without ICD, is good to have, in
> case pocl would be ported to some embedded devices. Something
> TTA-related springs to mind first. :)
>
> 3. ICD is currently easily disabled & removed entirely at buildtime from
> pocl. (configure --disable-icd)
>
> 4. Direct linking and ICD can co-exist with current pocl on mainstream
> systems (read: at least x86_64 debian ;).
> This can be done either with the trunk approach:
> -export the clXXX functions directly, and rely on the linker -Bsymbolic
> switch to not make infinate loops in ICD loaders.
> or Vincent's proposed patch:
> -rename the implementations to POclXXX and have ICD call these. The
> linker willing, we can still export also the clXXX API with a #define.
>
> 5. With Vincent's proposed merge, we could test either ICD or non-ICD
> version in the build tree without installing. (former requiring ocl_icd)
>
>
> So, I suggest we do the follwing:
> -we build only one libpocl (per build tree)
> -enable ICD per default, allowing user remove it if needed.
> -export the clXXX symbols, disabling them per platform or user request.
> This then means we use the POclXXX way.
> -a libOpenCL->libpocl link can be made if exporting is enabled, adding
> this check to the currently available ones. Perhaps even with a user
> override to dissallow?
I would propose that this link requires an explicit separate configure
option. By default, as proposed, we will build ICD and export symbols.
But, by default, we wont want that 'make install' overwrite libOpenCL.so
installed in the system (ICD loader).
> The only downside to this suggestion is that internally to pocl, we must
> call POclXXX functions, instead of clXXX ones, to not cause a infinite
> loop on a possible future platform that lacks the "-Bsymbolic" and/or
> some sort of noexport flag. On the upside, this allows for maximum
> flexibility w.r.t. future porting. Also, calling POclXXX instead of
> clXXX *within* pocl is perhaps not that bad thing anyways ;)
Note that the "-Wl,-z,defs" linker option I use will warn the developer
immediately if he uses a undefined symbol (ie clXXX instead of POclXXX).
It is the way I found all the clXXX to replace.
Regards,
Vincent
> Now would be a good time to point out that I misunderstood something
> crucial :)
>
> kalle
>
--
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: [email protected] 38330 Montbonnot Saint Martin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
