Hi, On 05/04/2014 13:04, Andreas Cadhalpun wrote: > You're right: the more serious problem is that nvidia-libopencl1 doesn't work > with a program build with ocl-icd-opencl-dev. > I just tested amd-libopencl1 and it works.
nvidia-libopencl1 only support OpenCL 1.1. If you use OpenCL 1.2 features, you need an libopencl1 that support it. From my point of view, this comes from a very bad design/specification in the norm. The norm comes from the Khronos group that has public forums but that did not seem to listen to this community. If you have free time, advocating here to better specify the binary interface would be very welcome. I do not have enough free time to do it myself (I can provide arguments and examples if someone want to do it) > Sorry for mixing things up here. If I install python-pyopencl apt > by installs amd-libopencl1. nvidia-libopencl1 was installed in my > build process to satisfy the dependencies of libavutil152. nvidia-libopencl1 is an old OpenCL ICD Loader implementation, only supporting OpenCL ICD implementing the 1.1 OpenCL version. Unless you really want to test/develop with all the NVidia OpenCL stack (and so be blocked at OpenCL 1.1), you should not use it. ocl-icd-libopencl1 and amd-libopencl1 are two replacements that must work. In particular, both of them are able to load and run the OpenCL ICD from NVidia (nvidia-opencl-icd). So, I would suggest to either depends on the virtual package (libopencl1) or on the free implementation (ocl-icd-libopencl1). But, here again, there is an issue in the norm: ocl-icd-libopencl1 and amd-libopencl1 can both use the NVidia ICD (nvidia-opencl-icd with a NVidia OpenCL implementation of OpenCL 1.1). However, there is no way for them to know that the NVidia ICD only support OpenCL 1.1. It means that, if you use OpenCL 1.2 functions in your program and your program select the NVidia ICD at run time, you will have errors (probably segfault as random values will be interpreted as function pointers). Here again, the good fix would be to push a better interface in the norm. It has not be done when OpenCL 2.0 arrives a few months ago :-( >>> But before you attempt this, I think you should coordinate with the >>> other packages currently providing these libraries and standardize >>> the symbol names. >> >> This is not possible unless you are able to modify the binaries >> provided by AMD, NVidia (and even Intel that, in its libopencl1.so >> library doe no even use the correct SONAME...) >> In any case, this is out the scope of the power of Debian Developer >> (AMD and NVidia are in non-free, not in main, Intel ones is not >> even in non-free due to an error in there licencing file. They promise >> me to correct this on a forum but I did not see any fact until now...) > > But the Debian Developer can ensure that nvidia-libopencl1 does not > provide libopencl1 as long as it doesn't work well together with the rest. libopencl1 means that this package provide a share library with the libopencl1. Please, look (again) at http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD in particular line 245 and following. It explains the role of all introduced virtual packages (I just see that I did not updated the name of all of them after the last discussion, ie for example libopencl-1.2-1 is still cited as libopencl1.2, but the reason is still correctly explained) Note that nvidia-libopencl1 does not provide libopencl-1.2-1 as it does not have support for 1.2 OpenCL functions. >>> ocl-icd-libopencl1 uses @OPENCL_*, while e.g. nvidia-libopencl1 uses >>> @BASE, so if a program is compiled with ocl-icd-opencl-dev and used >>> with nvidia-libopencl1 (which apt installs by default with the current >>> broken symbols file), it will produce errors like: >>> undefined reference to `clReleaseMemObject@OPENCL_1.0' >> >> Are you sure? When I test it a few months (years) ago, there was >> only a warning. Look at line 310 and following at >> http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD >> Perhaps the linker behavior changed since this time. > > Yes, I'm sure that I see this error. > When FFmpeg is compiled with ocl-icd-opencl-dev and then e.g. amarok is > compiled while nvidia-libopencl1 is installed instead of ocl-icd-libopencl1, > it results in: > [ 71%] Building CXX object > src/core-impl/collections/ipodcollection/CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o > cd src/core-impl/collections/ipodcollection && /usr/bin/c++ > -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=11 -DKDE_DEPRECATED_WARNINGS > -DMAKE_AMAROK_COLLECTION_IPODCOLLECTION_LIB -DQT_CORE_LIB -DQT_DBUS_LIB > -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_STL > -DQT_STRICT_ITERATORS -DQT_SVG_LIB -DQT_USE_FAST_CONCATENATION > -DQT_USE_FAST_OPERATOR_PLUS -DQT_XML_LIB -D_BSD_SOURCE -D_REENTRANT > -D_XOPEN_SOURCE=500 -g -O2 -fstack-protector --param=ssp-buffer-size=4 > -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fmessage-length=0 > -Wl,--as-needed -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align > -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions > -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual > -fno-threadsafe-statics -fvisibility=hidden -Werror=return-type > -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -fPIC -I. > -I../../../../../src/core-impl/collections/ipodcollection > -I../../../../../shared -I../../../../shared > -I../../../../../src -I../../.. -I/usr/include/KDE -I/usr/include/qt4/phonon > -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml > -I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtUiTools > -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql > -I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript > -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4/QtNetwork > -I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner > -I/usr/include/qt4/QtDeclarative -I/usr/include/qt4/QtDBus > -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui > -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt > -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 > -I/usr/include/glib-2.0/gobject -I/usr/include/gpod-1.0 > -I/usr/include/libxml2 -I/usr/include/p11-kit-1 -D_GNU_SOURCE > -D_LARGEFILE64_SOURCE -o > CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o -c > ../../../../../src/core-impl/collections/ipodcollection/IpodCollectionFactory.cpp > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clReleaseMemObject@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clReleaseCommandQueue@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clSetKernelArg@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clGetPlatformInfo@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clEnqueueUnmapMemObject@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clCreateProgramWithSource@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clCreateContextFromType@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clCreateCommandQueue@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clEnqueueMapBuffer@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clCreateBuffer@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clBuildProgram@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clGetDeviceIDs@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clGetDeviceInfo@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clReleaseContext@OPENCL_1.0' > //usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to > `clGetPlatformIDs@OPENCL_1.0' > collect2: error: ld returned 1 exit status > make[3]: *** [src/amarok] Error 1 Oh! This is a problem at link-time between objects/libraries compiled with different ICD Loader. This is something I never tested. We will have to deal with it, indeed. Please, can you open a new bugreport with this so that we can track this problem ? >>> This happens in my use case: >>> I packaged FFmpeg for Debian [2]. Adding opencl support breaks the >>> compilation of many possible reverse dependencies due to this problem. >> >> I do not really understand what you mean. If the linker did not change >> its behavior, then the chosen solution (versioned symbols) allowed >> all possible runtimes (sometimes at the expense of a warning). > > Did anyone ever test to compile a third program with a different libopencl1 > provider installed? I can imagine that there might be a difference between > run-time and compile-time. I give you a pointer to the place where I put the result of such experiments. I will redo them to check if the results are still up-to-date. I tested all combination between compiling a program with a libopencl1 and running this compiled program with any libopencl1. If I understand correctly, your problem described before is not the same. It is about the compatibility of different libraries/objects at link time. > It would be better if NVidia could be convinced to use the same symbols > as ocl-icd and AMD, but if they don't, they shouldn't use the same > virtual packages. It would be great if the Khronos group provides a free implementation of its loader instead of giving partial, incomplete specification and letting each vendor to provide their own one :-( Regards, Vincent > Best regards, > Andreas -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
