Le 31/08/2012 20:09, Carlos Sánchez de La Lama a écrit : > El 31/08/2012, a las 16:40, Vincent Danjean escribió: > > I am unsure if ICD spec allows full paths in > etc/OpenCL/vendors/xxx.icd files (can someone confirm this?)
You can put full path and/or only libname. The string is dlopened. If this is not a full path, dlopen will look in standard library search path. With my hat of Debian maintainer and thinking about multiarch, I would really prefer a single filename (that will be searched in the arch specific library search paths) >> However, at compile time, programs linked against libOpenCL.so >> would register the POCL SONAME (ie libpocl.so.1), so they would not >> be executable if POCL is remove in flavor of AMD implementation for >> example. > > And this is wrong. Programs linked against pocl should work with > AMD/nVIDIA or whatever. So changing the pocl library name is > something we should do at some point (probably soon as pocl > stops being a "developers only" package). As soon pocl stops being a "developers only" package, it will be used as an ICD, as the ones from NVidia, Intel and AMD. None of these vendors suggest to link directly with their ICD (and only Intel expose the required symbols that would allow direct linking, however with the libintelocl.so SONAME, in a file with the same name). Programs that should work with different OpenCL version will use an ICD Loader. By the way, note that the library interface is not fully defined (SONAME libOpenCL.so or libOpenCL.so.1, usage of versionned symbols or not). All of this already exists. See some comments in http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD If I had to class OpenCL ICD loaders with respect to their coding, I would place: first AMD and ocl-icd (libOpenCL.so.1 soname, versionned symbols) then NVidia (libOpenCL.so.1 soname, non versionned symbols) then Intel (libOpenCL.so soname, non versionned symbols). >> Otherwise said: either pocl provide an ICD (and programs go through >> the ICD loader) and/or libpocl.so.1 is used directly. But do not try >> to put libpocl.so.1 as libOpenCL.so.1 without compiling it like that >> at the start. And I really do not see any benefit to do that now >> that a free ICD loader exists. > > Ok, symlinking/renaming is thus discarded. I still see a small benefit > on not depending on an ICD loader, if it is doable. For testing or in constrained environment (embedded platform), yes, perhaps. Perhaps the removal of the ICD loader can be interesting. Else, no. ICD loader is the way to go. People want to be able to use several OpenCL implementations (depending on the targeted hardware, to use the most efficient on their programs, ...) without having to play with installation/removing of several libraries with the same name (libOpenCL.so.1). ICD has been designed for this reason and all other vendors moved to it. > But if ICD does not allow full names in xxx.icd files, meaning > libpocl.so.1 has to keep this name, then I would go to an ICD only > unless someone thinks of another solution. Having the OpenCL > applications link against libpocl.so instead of libOpenCL.so is > weird and prevents using pocl as a real OpenCL development library. Whereas ICD does allow full names, I really think that keeping the name libpocl.so.1 would be the good think to do. Keeping non ICD support (ie still exporting directly OpenCL symbols), even with a different SONAME, have two advantages: * pocl can be used in constrained environment where we want to avoid an ICD loader because we know that POCL will be the only one implementation and we are really short in memory * pocl can be used directly for debug, avoiding an additional layer And yes, linking directly to libpocl would be exceptional. It is not possible for AMD and NVidia. It is theoretically possible with Intel (but not with libOpenCL.so.1 soname) Regards, Vincent -- 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
