Hi,
On 05.04.2014 16:24, Vincent Danjean wrote:
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.
I'm not using OpenCL 1.2. I'm merely referring to the link-time error
below. In the README, you provided a link to, I found:
- libOpenCL.so.1 must have its symbols versionned
[proposed, not right for the intel and nvidia ones]
So probably the link-time issue is with both the intel and nvidia libraries.
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)
Unfortunately I also don't have too much free time, so I can't help here.
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).
I'm not manually depending on it. It's just that due to this bug, apt
installed nvidia-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 :-(
It seems this norm really needs improvement. :(
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:
[...]
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 ?
Against which package(s) should this be reported?
(I'm tempted to report this against libopencl1, but unfortunately a
virtual package has no maintainer.)
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.
Yes, my problem is a link-time issue.
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 :-(
Indeed. :(
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
