Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On Mon, 2023-06-19 at 11:04 +0100, Simon McVittie wrote: > Older Intel integrated GPUs are not very fast anyway, so this might not > be a particularly significant loss. Plenty fast enough to run the FOSS 3D games in Debian like 0ad though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: opencl-icd virtual package(s)?
(beignet's FTBFS is #974792, my previous attempts to fix it are in Salsa, and I was planning to remove it and accept that older hardware would only be able to use CPU (pocl) OpenCL. Please use that bug for further discussion of that.) I'd leave the loader packages alone, i.e. ocl-icd-libopencl1 stays the default, and the libopencl1 virtual package continues to exist. (And yes, loaders are not ICDs, so libreoffice Suggesting them as alternatives to each other is probably a bug.) For the actual ICDs themselves, yes, my proposal was to have a metapackage depending on all the DFSG-free ones, and also keep the existing opencl-icd virtual package. Paul Wise wrote: > maybe now is the time to do this, so that the problems can be found via bug reports? Simon Richter wrote: > Yes, but the others correctly report that no hardware can be found, and it's up to the application to disregard them. This generally works, because pocl also reports "no hardware can be found" if you ask for a GPU, so this is a well-tested code path. Not necessarily: not every application asks for a GPU (rather than 'any OpenCL device'), and if the application silently falls back to running without OpenCL on failure, it might not be obvious that it didn't find OpenCL when it should have done. Since ocl-icd 2.2.5, ocl-icd-libopencl1 sorts the ICDs to make the first one a reasonable default choice, which fixed some issues of this kind, but not all of them. These look like they'd still have issues: https://sources.debian.org/src/asl/0.1.7-4/src/acl/aclHardware.cxx/#L70 https://sources.debian.org/src/erlang-cl/1.2.4-1/c_src/cl_nif.c/#L6759 (maybe) https://sources.debian.org/src/ocl-icd/2.3.2-1/ocl_icd_loader.c/#L1249 (if the device type you ask for isn't the first platform's type) and there may be more.
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
At the risk of stating the obvious, OpenCL seems to be "the same shape"
as many other GPU-related APIs like GLX, EGL, Vulkan, VA-API and VDPAU:
- applications link to a loader library
- the loader library dlopens a concrete implementation of OpenCL
(an "ICD", Installable Client Driver)
- hopefully it chooses an ICD that will work on your hardware
- most ICDs are specific to a class of hardware, for instance one for all
AMD GPUs
- there is one ICD that runs on the CPU and has no special GPU requirements
(for GL this is llvmpipe, for Vulkan it's lavapipe, for OpenCL it's pocl)
Given that, it would probably make sense for the packaging of OpenCL to be
"the same shape" as the other GPU-related APIs.
As far as I understand it, there are two different models in the
graphics world:
- in GLX, EGL, VA-API and VDPAU, only one ICD gets loaded (hopefully the
right one)
- in Vulkan, every ICD gets loaded, and ICDs for hardware you don't have
are expected to report "no supported devices" in a graceful way; and
if you have more than one ICD supporting the same hardware, or more than
one GPU, or a software driver like lavapipe, then the application is
offered a choice between all the possible devices and will hopefully
choose an appropriate one to render on
It sounds as though OpenCL is more similar to Vulkan here?
It seems unfortunate that ocl-icd-libopencl1 has "icd" in its name,
but is not an ICD (instead it's an ICD loader). I believe that's because
ocl-icd is the source package name?
On Mon, 19 Jun 2023 at 13:01:21 +0900, Simon Richter wrote:
> Since these provide a shared library with a fixed name, the ICD loaders
> either need to conflict or provide alternatives.
Is there an obvious "best" loader - perhaps ocl-icd-libopencl1 - that
we can choose to be the only one that Debian supports, similar to
the way we use GLVND for GLX/EGL and the reference Vulkan-Loader for
Vulkan? It seems to me that the ecosystem would be simpler if the ICDs,
which should in principle be the only thing that is hardware-specific,
were the only thing that involves a choice.
(In particular, NVIDIA ship their own binary build of an unknown and
possibly patched version of GLVND with their drivers, but we don't
package that: we use the one built by us from src:libglvnd instead.)
On Mon, 19 Jun 2023 at 12:10:22 +0800, Paul Wise wrote:
> Package: some-opencl-using-package
> Recommends: opencl-icd-all | opencl-icd
Presumably it should also depend on ocl-icd-libopencl1 | libopencl1,
via ${shlibs:Depends}, since it will link to libOpenCL.so.1 and that's
usually going to be a hard dependency?
Perhaps it should be the loader that has a Recommends or Depends on
a selection of suitably high-quality Free ICDs?
In GLX and EGL, the loader Depends on Mesa's ICD.
In Vulkan, the loader Recommends Mesa's ICDs (there are several in one
package).
OpenCL is a bit more complicated than GLX/EGL/Vulkan here because the
Intel and on-CPU OpenCL drivers aren't part of Mesa, so there is no
completely obvious choice; so I agree that a metapackage that pulls in
all the (sufficiently high-quality) Free ICDs is probably useful to have.
> Depends:
> opencl-icd-all-free,
> nvidia-legacy-340xx-opencl-icd,
> nvidia-legacy-390xx-opencl-icd,
> nvidia-opencl-icd,
I'm not sure this is a good idea: having multiple versions of the
NVIDIA proprietary driver installed at the same time doesn't seem very
supportable, since only one of them (the one that matches the loaded
kernel module) will actually work.
Instead, I think nvidia*-driver-libs should probably pull in the
appropriate NVIDIA OpenCL ICD as a Depends/Recommends/Suggests (depending
on how important Debian considers OpenCL to be), the same way it currently
pulls in GLX and EGL as Depends, and GLES and Vulkan as Suggests.
Are there any significant proprietary OpenCL drivers other than NVIDIA's?
> > I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but
> > never actually did it, partly because there are applications that
> > implicitly assume that all the installed ICDs work, and may fail to find
> > the usable ICD if there are unusable ones installed. (I consider this
> > to be a bug in the application, but finding and fixing these would take
> > time.)
>
> Since we just opened trixie for development, maybe now is the time
> to do this, so that the problems can be found via bug reports?
As mentioned above, I believe Vulkan works this way.
> > intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd,
> > which as you note, no longer builds)
>
> Unfortunately intel-opencl-icd can't replace beignet-opencl-icd
> because the former doesn't support old hardware. At least on my
> system, clinfo says only pocl and beignet have supported devices.
If beignet-opencl-icd no longer builds, then we can't ship it, however
much your older hardware might benefit from it. I think for trixie your
older hardware will have to fall back to running
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On 19/06/2023 06.10, Paul Wise wrote: On Sun, 2023-06-18 at 07:28 +0100, Rebecca N. Palmer wrote: Hence, such a package would need to Depend on or Recommend *all* the ICDs, similar to xorg-xserver-video-all. Ah. So considering what Vincent said, something like this? Should we distinguish between the device types CPU and GPU? CPU devices are likely available on buildds, ci-infrastructure, ... AFAICS CPU would be pocl-opencl-icd (but only available on x86, arm), all others should be GPU. (pocl supports more devices, e.g. cuda, vulkan, ... but so far we only build and ship the cpu drivers) pocl (cpu) builds for most platforms, but selftests are failing due to wrong results which seems to be a code generation issue either in pocl or llvm. Package: some-opencl-using-package Recommends: opencl-icd-all | opencl-icd Package: opencl-icd-all Section: metapackages Depends: beignet-opencl-icd, intel-opencl-icd, mesa-opencl-icd, pocl-opencl-icd, Package: opencl-icd-all-non-free Section: non-free/metapackages Depends: opencl-icd-all-free, nvidia-legacy-340xx-opencl-icd, nvidia-legacy-390xx-opencl-icd, nvidia-opencl-icd, nvidia-tesla-418-opencl-icd, nvidia-tesla-450-opencl-icd, nvidia-tesla-460-opencl-icd, nvidia-tesla-470-opencl-icd, nvidia-tesla-510-opencl-icd, nvidia-tesla-opencl-icd, The nvidia bits must be an ored list of alternatives, we don't want to pull in more than one driver. Leaving out all the EoL and transitional bits, this boils down to nvidia-opencl-icd | nvidia-tesla-opencl-icd | nvidia-tesla-470-opencl-icd for bookworm and trixie (at least for now, but I don't expect a new nvidia driver split (due to cards getting deprecated) soon) Andreas
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On Sun, 2023-06-18 at 07:28 +0100, Rebecca N. Palmer wrote: > Hence, such a package would need to Depend on or Recommend *all* the > ICDs, similar to xorg-xserver-video-all. Ah. So considering what Vincent said, something like this? Package: some-opencl-using-package Recommends: opencl-icd-all | opencl-icd Package: opencl-icd-all Section: metapackages Depends: beignet-opencl-icd, intel-opencl-icd, mesa-opencl-icd, pocl-opencl-icd, Package: opencl-icd-all-non-free Section: non-free/metapackages Depends: opencl-icd-all-free, nvidia-legacy-340xx-opencl-icd, nvidia-legacy-390xx-opencl-icd, nvidia-opencl-icd, nvidia-tesla-418-opencl-icd, nvidia-tesla-450-opencl-icd, nvidia-tesla-460-opencl-icd, nvidia-tesla-470-opencl-icd, nvidia-tesla-510-opencl-icd, nvidia-tesla-opencl-icd, > I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but > never actually did it, partly because there are applications that > implicitly assume that all the installed ICDs work, and may fail to find > the usable ICD if there are unusable ones installed. (I consider this > to be a bug in the application, but finding and fixing these would take > time.) Since we just opened trixie for development, maybe now is the time to do this, so that the problems can be found via bug reports? > intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, > which as you note, no longer builds) Unfortunately intel-opencl-icd can't replace beignet-opencl-icd because the former doesn't support old hardware. At least on my system, clinfo says only pocl and beignet have supported devices. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
Hi, On 6/19/23 01:37, Vincent Danjean wrote: All we can do with the dependency system (not yet done) would be to force a dependency on a new virtual package to ensure that at least one ICD with the correct minimal version is available. I'm not sure if this is really possible (is it possible to install several packages providing the same virtual package ?) Yes, that is fine. The typical pattern for most packages that provide virtual packages is to also conflict with the same virtual package, because that doesn't make sense, but if you don't declare that conflict, packages will happily co-install. Since these provide a shared library with a fixed name, the ICD loaders either need to conflict or provide alternatives. Simon
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
Le 18/06/2023 à 08:28, Rebecca N. Palmer a écrit :
On 18/06/2023 03:37, Paul Wise wrote:
Presumably any of the OpenCL ICDs work for most packages?
For most OpenCL-using *packages* but not most *hardware*. (Except for
pocl-opencl-icd, which works nearly everywhere but is slow.)
Perhaps there should be a default-opencl-icd virtual package?
Hence, such a package would need to Depend on or Recommend *all* the ICDs,
similar to xorg-xserver-video-all.
I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but never
actually did it, partly because there are applications that implicitly assume
that all the installed ICDs work, and may fail to find the usable ICD if there
are unusable ones installed. (I consider this to be a bug in the application,
but finding and fixing these would take time.)
This is problematic, because some icd are in main (pocl), others are in
non-free (nvidia).
In fact, there is a problem since the beginning with OpenCL dependencies.
When a program uses OpenCL, it links against a ICD Loader that will dynamically
load the available ICD.
There are different versions of OpenCL.
An ICD Loader supporting OpenCL x should also support OpenCL y<=x (there are a
few exceptions, but I will ignore them for now)
This is provided by the virtual package libopencl1 (and the ocl-icd-libopencl1
in main).
All OpenCL programs should only depend on the (versionned) libopencl1 virtual
package. If using ocl-icd-opencl-dev, this is done automatically.
An OpenCL program can suggest/recommend one/some ICD packages but the ICD
selection is done at runtime.
Reusing the commands from the first mail (but restricting to Depends only),
only 4 packages really depends on a specific ICD:
$ grep-aptavail --no-field-names --show-field Package --field Depends
--whole-pkg '(' --pattern .*opencl-icd.* --and --not --pattern
'^opencl-icd(-1\.[1]2-1)?$' ')' | sort -u
hashcat
hashcat-nvidia
libhmsbeagle1v5
python3-pyopencl
For python3-pyopencl, it seems a false positive (depends on pocl-opencl-icd |
mesa-opencl-icd | opencl-icd). However, it might be better to move this to a
recommends (one can install a ICD without using a Debian package).
For libhmsbeagle1v5 also (depends on mesa-opencl-icd | opencl-icd), however it
does not depends on an ICD Loader! (libopencl1)
Same for hashcat (depends on pocl-opencl-icd | opencl-icd) and it also does not
depend on an ICD Loader!
hashcat-nvidia seems a metapackage forcing the installation of
nvidia-opencl-icd or nvidia-legacy-390xx-opencl-icd (but, as it depends on the
hashcat package for the program, I doubt that the nvidia implementation will be
used if another one is presented by default to the program)
An ICD Loader supporting OpenCL x means that it provides all symbols required for
OpenCL x (that are a supersede of symbols for OpenCL y
PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
only OpenCL ICD implementation package I can see that supports Intel
Ivy Bridge, but it is hard to tell which other packages support this,
because some descriptions don't mention which hardware is supported.
I think of it as
intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, which
as you note, no longer builds)
mesa-opencl-icd = ATI GPUs (including AMD integrated GPUs)
pocl-opencl-icd = CPUs
but that might be out of date.
Re: [Pkg-opencl-devel] opencl-icd virtual package(s)?
On 18/06/2023 03:37, Paul Wise wrote: Presumably any of the OpenCL ICDs work for most packages? For most OpenCL-using *packages* but not most *hardware*. (Except for pocl-opencl-icd, which works nearly everywhere but is slow.) Perhaps there should be a default-opencl-icd virtual package? Hence, such a package would need to Depend on or Recommend *all* the ICDs, similar to xorg-xserver-video-all. I have proposed this before (see 31-Jan-2015 pkg-opencl-devel), but never actually did it, partly because there are applications that implicitly assume that all the installed ICDs work, and may fail to find the usable ICD if there are unusable ones installed. (I consider this to be a bug in the application, but finding and fixing these would take time.) PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the only OpenCL ICD implementation package I can see that supports Intel Ivy Bridge, but it is hard to tell which other packages support this, because some descriptions don't mention which hardware is supported. I think of it as intel-opencl-icd = Intel integrated GPUs (replacing beignet-opencl-icd, which as you note, no longer builds) mesa-opencl-icd = ATI GPUs (including AMD integrated GPUs) pocl-opencl-icd = CPUs but that might be out of date.
Re: opencl-icd virtual package(s)?
On Sun, 2023-06-18 at 10:37 +0800, Paul Wise wrote:
> [BCCed to OpenCL ICD implementation package maintainers]
>
> I noticed that some packages have a dep on specific OpenCL ICD
> packages, but don't dep on the opencl-icd virtual package(s).
> Presumably any of the OpenCL ICDs work for most packages?
Theoretically any of them is expected to work. That's the point of ICD.
But, while I'm not an OpenCL user, I have heard that different OpenCL
implementations have their own quirk... (forgotten source)
> $ grep-aptavail --no-field-names --show-field Package --field
> Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
> and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'
>
> In addition, I noticed that hashcat-nvidia (which presumably doesn't
> need to depend on the opencl-icd virtual package) only depends on two
> of the nvidia OpenCL ICD packages, while there are lots of other nvidia
> OpenCL ICD packages that presumably work too.
It won't surprise me if .*-nvidia fails to work with a non-nvidia OpenCL
implementation.
> I have attached a package list and dd-list for these issues.
>
> Perhaps there should be a default-opencl-icd virtual package?
Usable OpenCL implementation is very device specific. We cannot make
sure what OpenCL implementation will always be avaialble on user devices,
and even our buildd.
If there must be a default, pocl-opencl-icd is the solution. It supports runing
OpenCL kernels on CPU, so it should be working on most hosts.
Just don't expect any higher performance from CPU-based OpenCL.
FYI: to verify what OpenCL is usable on your host, you may just
$ sudo apt install clinfo; clinfo
> Perhaps lintian should flag situations where the dep isn't just
> default-opencl-icd | opencl-icd? or is missing opencl-icd?
>
> Thoughts?
I think the current status for some typical packages, like python3-pyopencl
is already correct.
$ apt show python3-pyopencl
Depends: ..., pocl-opencl-icd | mesa-opencl-icd | opencl-icd, ...
You see pocl there as the first choice. For any other packages
that depend on opencl, I think maintainers might have an idea
on what opencl implementation is preferred, either inclusively
or exclusively.
> PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
> only OpenCL ICD implementation package I can see that supports Intel
> Ivy Bridge, but it is hard to tell which other packages support this,
> because some descriptions don't mention which hardware is supported.
It looks the intel-opencl-icd does not support very old CPUs,
(as listed here https://github.com/intel/compute-runtime )
but I think most major users of OpenCL depends on dedicated GPUs.
The performance of integrated graphics seems no different than nothing.
I think all OpenCL ICD providers can be found by $ apt search opencl-icd .
The AMD opencl implementation is missing.
It is a part of ROCm (https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime
),
and indeed something to work on for the ROCm team in the
future.
opencl-icd virtual package(s)?
[BCCed to OpenCL ICD implementation package maintainers]
I noticed that some packages have a dep on specific OpenCL ICD
packages, but don't dep on the opencl-icd virtual package(s).
Presumably any of the OpenCL ICDs work for most packages?
$ grep-aptavail --no-field-names --show-field Package --field
Depends,Recommends,Suggests --whole-pkg '(' --pattern .*opencl-icd.* --
and --not --pattern '^opencl-icd(-1\.[1]2-1)?$' ')'
In addition, I noticed that hashcat-nvidia (which presumably doesn't
need to depend on the opencl-icd virtual package) only depends on two
of the nvidia OpenCL ICD packages, while there are lots of other nvidia
OpenCL ICD packages that presumably work too.
I have attached a package list and dd-list for these issues.
Perhaps there should be a default-opencl-icd virtual package?
Perhaps lintian should flag situations where the dep isn't just
default-opencl-icd | opencl-icd? or is missing opencl-icd?
Thoughts?
PS: I noticed this because beignet-opencl-icd is RC-buggy. This is the
only OpenCL ICD implementation package I can see that supports Intel
Ivy Bridge, but it is hard to tell which other packages support this,
because some descriptions don't mention which hardware is supported.
--
bye,
pabs
https://wiki.debian.org/PaulWise
hashcat
leela-zero
libhmsbeagle1v5
libreoffice-calc
libpocl2
python3-pyopencl
boinc-client-opencl
hashcat-nvidia
nvidia-opencl-dev
nvidia-libopencl1
nvidia-opencl-common
beignet-dev
intel-opencl-icd-dbgsym
mesa-opencl-icd-dbgsym
beignet-opencl-icd-dbgsym
Andreas Beckmann
pyopencl (U)
Andreas Tille
libhmsbeagle (U)
Chris Halls
libreoffice (U)
Daniel Echeverry
hashcat (U)
Debian BOINC Maintainers
boinc
Debian LibreOffice Maintainers
libreoffice
Debian Med Packaging Team
libhmsbeagle
Debian OpenCL Maintainers
pyopencl
Debian Security Tools
hashcat
hashcat-meta
Gianfranco Costamagna
boinc (U)
Guo Yixuan (郭溢譞)
boinc (U)
Raphaël Hertzog
hashcat-meta (U)
Rene Engelhard
libreoffice (U)
Steffen Moeller
boinc (U)
Tomasz Rybak
pyopencl (U)
Ximin Luo
leela-zero
signature.asc
Description: This is a digitally signed message part
