Hi,
while implicitly recommending amd-opencl-icd is not such a bad idea (it
comes with a CPU implementation as well, so is usable for many people
even without proprietary graphics cards), perhaps it's better not to
Recommend a "random" icd by default and require explicit installation of
the required icd.
Package: ocl-icd-libopencl1
Suggests: opencl-icd
# require explicit installation of an icd
Package: vendor-libopencl1:
Recommends: vendor-opencl-icd, opencl-icd
# user probably wants exactly this if he installs vendor driver
# and switching loader vendors should not "orphan" foreign icds
(yes, comma, not pipe)
Package: vendor-opencl-icd
Depends: ocl-icd-libopencl1 | vendor-libopencl1 | libopencl1
# yes, we want to get bug reports for ocl-icd loader working not
# properly with vendor icd implementations
or
Package: vendor-opencl-icd
Depends: vendor-libopencl1 | libopencl1
# use the well-tested driver from first vendor to be installed
# should avoid any possible interoperability problems
# probably more multiarch conflicts
(install ocl-icd-libopencl1; install vendor-opencl-icd:foreign)
For clinfo:
Package: vendor-clinfo
Suggests: opencl-icd
# require explicit icd installation
or
Package: vendor-clinfo
Depends: ocl-icd-libopencl1 | libopencl1
Recommends: opencl-icd, vendor1-opencl-icd, vendor2-opencl-icd
# recommend all to get a better out-of-the-box result
Maybe we should provide some more virtual packages in the -icd packages:
opencl-icd-gpgpu // or is there a better term that covers
// Nvidia GTX xyz, Nvidia Tesla, Radeon HD wxyz
opencl-icd-gpgpu-$VENDOR
opencl-icd-cpu
opencl-icd-cpu-$CPUVENDOR
Would it be useful to make clinfo M-A: same co-installable? Rename the
binaries to clinfo-$ARCH or $ARCH-clinfo (fsvo ARCH, maybe better the
multiarch triplet) and a clinfo wrapper script that runs the one for the
primary arch (and thereafter for the secondary arches ?) Maybe amend the
output a bit if there are more than one binary to be run, but keep the
original output if there is only one.
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
