Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Obtenir le support des images avec opencl
29 views
Skip to first unread message
benoit
Aug 9, 2021, 9:40:03 AM8/9/21
to
Bonjour à toutes et tous,
En bref voici mon problème :
clinfo | grep Image
Image support..................... No
En détail :
Quand je lance darktable avec ces
options pour comprendre pourquoi il n’utilise pas opencl pourtant
installé, il me dit ceci :
$ darktable -d opencl -d per
------------------------------8<--
0.081940 [opencl_init] discarding device 0 `AMD Radeon(TM) Vega 8
Graphics (RAVEN, DRM 3.40.0, 5.10.0-7-amd64, LLVM 11.0.1)' - The
OpenCL driver doesn't provide image support. See also 'clinfo'
output.
0.081945 [opencl_init] no suitable devices found.
0.081948 [opencl_init] FINALLY: opencl is NOT AVAILABLE on this
system.
0.081949 [opencl_init] initial status of opencl enabled flag is
OFF.
-----------------------
Du coup je fais ce qu’il dit, je
lance clinfo et je cherche à Image :
clinfo | grep Image
Image support..................... No
Comment y remédier ?
Merci d'avance
--
Benoît
didier gaumet
Aug 9, 2021, 4:00:03 PM8/9/21
to
Bonjour,
Je n'ai jamais expérimenté OpenCL, donc mes commentaires sont à prendre avec précaution
De ce que je comprends (de travers?), à l'heure actuelle la seule implémentation d'OpenCL qui prendrait en charge le support des images serait ROCm à partir de la version 3.7 (on en est à 4.3). En tout cas pour de l'AMD/ATI, tu peux utiliser Mesa mais le support des images ne semble pas encore d'actualité.
Je n'ai trouvé trace de ROCm dans Debian qu'en version 3.3 de mai 2020 dans le repo experimental donc je suppose que c'est abandonné. Je n'ai trouvé de trace de ROCm dans aucun autre package (mais j'ai peut-être mal cherché)
Tu peux peut-être t'en sortir en installant un paquetage Ubuntu (module ROCm DKMS) à partir des dépôts AMD, ça ne coûte rien de lire leur page de doc.
https://wiki.archlinux.org/title/GPGPU
https://www.phoronix.com/scan.php?page=news_item&px=ROCm-3.7-OpenCL-Image
https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html
Je n'ai jamais expérimenté OpenCL, donc mes commentaires sont à prendre avec précaution
De ce que je comprends (de travers?), à l'heure actuelle la seule implémentation d'OpenCL qui prendrait en charge le support des images serait ROCm à partir de la version 3.7 (on en est à 4.3). En tout cas pour de l'AMD/ATI, tu peux utiliser Mesa mais le support des images ne semble pas encore d'actualité.
Je n'ai trouvé trace de ROCm dans Debian qu'en version 3.3 de mai 2020 dans le repo experimental donc je suppose que c'est abandonné. Je n'ai trouvé de trace de ROCm dans aucun autre package (mais j'ai peut-être mal cherché)
Tu peux peut-être t'en sortir en installant un paquetage Ubuntu (module ROCm DKMS) à partir des dépôts AMD, ça ne coûte rien de lire leur page de doc.
https://wiki.archlinux.org/title/GPGPU
https://www.phoronix.com/scan.php?page=news_item&px=ROCm-3.7-OpenCL-Image
https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html
Polyna-Maude Racicot-Summerside
Aug 9, 2021, 6:40:02 PM8/9/21
to
Bonjour Didier,
Je ne sais pas trop exactement et avec précision ce que tu veux dire par
"support des images" parce que déjà OpenCL permet grace à la
parallélisation de traiter sur le GPU des images.
Exemple ceci qui est du code Python :
https://towardsdatascience.com/get-started-with-gpu-image-processing-15e34b787480
Déjà Darktable utilise le GPU pour traiter des images, donc je ne crois
pas que l'on peut dire que c'est absent de Debian.
Il faut faire attention entre implémentation et implémentation de référence.
Par exemple dans le cas de Java, peut-on dire que Debian inclus Java ?
Il n'inclus pas la version de référence de Java tel que produit par
Oracle mais il inclus une version aux fonctionnalités et à la
compatibilité identique nommé OpenJDK (qui est en partie produite par
Oracle à ce que j'en comprends).
Si tu regardes la page de ArchLinux, tu veras dans le haut plusieurs
gestionnaire (driver) pour OpenCL.
*rocm* est l'un d'eux
Tout comme *opencl-amd* et *opencl-mesa*
De ce que je comprend de ArchLinux, le package opencl-amd est équivalent
à ce qui se trouve actuellement dans *non-free*.
https://aur.archlinux.org/packages/opencl-amd/
Solidairement,
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
"support des images" parce que déjà OpenCL permet grace à la
parallélisation de traiter sur le GPU des images.
Exemple ceci qui est du code Python :
https://towardsdatascience.com/get-started-with-gpu-image-processing-15e34b787480
Déjà Darktable utilise le GPU pour traiter des images, donc je ne crois
pas que l'on peut dire que c'est absent de Debian.
Il faut faire attention entre implémentation et implémentation de référence.
Par exemple dans le cas de Java, peut-on dire que Debian inclus Java ?
Il n'inclus pas la version de référence de Java tel que produit par
Oracle mais il inclus une version aux fonctionnalités et à la
compatibilité identique nommé OpenJDK (qui est en partie produite par
Oracle à ce que j'en comprends).
Si tu regardes la page de ArchLinux, tu veras dans le haut plusieurs
gestionnaire (driver) pour OpenCL.
*rocm* est l'un d'eux
Tout comme *opencl-amd* et *opencl-mesa*
De ce que je comprend de ArchLinux, le package opencl-amd est équivalent
à ce qui se trouve actuellement dans *non-free*.
https://aur.archlinux.org/packages/opencl-amd/
Solidairement,
--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development
didier gaumet
Aug 10, 2021, 3:50:03 AM8/10/21
to
Alors, clairement, je suis ignorant en tout ce qui touche traitement d'image, délégation de calculs à un processeur graphique, parallélisation. Donc Darktable, OpenCL, ROCm, qui rentrent à divers titres dans cette liste me sont étrangers
Ce que j'ai déduit (peut-être à tort) c'est que ROCm est une couche open-source proposée par AMD, utilisant et implémentant OpenCL pour déléguer, de manière parallélisée le cas échéant, des calculs à des processeurs graphiques AMD/ATI (et Intel aussi, a priori)
Que personne ne me demande d'élaborer, je serais bien en peine de le faire, mais le standard OpenCL 2.0 introduit la prise en compte des images (MESA implémente OpenCL 1.2, ROCm récent implémente OpenCL 2.2). (cf page Wikipedia en anglais d'OpenCL)
Pure *spéculation* de ma part, vu que je n'y connais vraiment rien: peut-être que "prise en charge des images" signifie ici "prise en charge des calculs sur images directement dans un format natif comme raw ou jpeg plutôt que comme des flots de données numériques génériques"
Pour ce qui est de Debian non-free, j'ai l'*impression* que ROCm est purement libre, donc n'y figurerait pas. Et que depuis que fglrx a été abandonné au profit de amdgpu-pro, il n'y a plus rien concernant les GPU AMD dans non-free
Pour les implémentations de drivers (ICD) OpenCL dans debian, le paquet virtuel opencl-icd liste des solutions Mesa, Intel, Nvidia et Pocl (pour les CPU apparemment même si on doit pouvoir adapter pour les GPU). Rien concernant AMD.
Étienne Mollier
Aug 10, 2021, 3:50:03 PM8/10/21
to
Bonjour Benoît, Bonjour Didier,
didier gaumet, on 2021-08-09:
L'implémentation OpenCL 1.2 de Mesa, fournie par le paquet
Debian mesa-opencl-icd, ne prend pas en charge le "Image
support", du moins pas sur ma carte RX560 :
$ clinfo | grep Image
Image support No
Un moyen de tricher est d'utiliser le paquet pocl-opencl-icd ;
c'est la version portable d'OpenCL. Mais bon, l'intérêt est
limité, on ne tourne que sur le processeur, pas sur la puce
d'accélération graphique :
$ clinfo
[…]
Platform Name Portable Computing Language
Number of devices 1
Device Name pthread-AMD Ryzen 5 3600 6-Core Processor
[…]
Image support Yes
Max number of samplers per kernel 16
Max size for 1D images from buffer 1073741824 pixels
Max 1D or 2D image array size 2048 images
Max 2D image size 32768x32768 pixels
Max 3D image size 2048x2048x2048 pixels
Max number of read image args 128
Max number of write image args 128
[…]
Je confirme également que l'implémentation d'OpenCL 2.0 dans
ROCm 4.3 prend en charge le "Image support":
$ /opt/rocm-4.3.0/opencl/bin/clinfo | grep Image
Image support: Yes
J'ignore toutefois si ROCm 4.3 va supporter la puce Vega 8.
> Je n'ai trouvé trace de ROCm dans Debian qu'en version 3.3 de mai 2020 dans le repo experimental donc je suppose que c'est abandonné. Je n'ai trouvé de trace de ROCm dans aucun autre package (mais j'ai peut-être mal cherché)
Effectivement, les travaux d'empaquetage sont en cours [1]. Il
y encore eu des discussions ces derniers mois sur l'ordre dans
lequel compiler les différents composants. La période de gel a
pas mal ralenti l'ensemble des projets en cours ces sept
derniers mois, et peut-être que l'empaquetage de ROCm en a aussi
fait les frais (ça et la nécessité d'avoir du matériel adéquat à
portée de main : les GPU AMD sont devenus subitement assez rares
de nos jours).
[1] : https://salsa.debian.org/rocm-team
> Tu peux peut-être t'en sortir en installant un paquetage Ubuntu (module ROCm DKMS) à partir des dépôts AMD, ça ne coûte rien de lire leur page de doc.
>
> https://wiki.archlinux.org/title/GPGPU
> https://www.phoronix.com/scan.php?page=news_item&px=ROCm-3.7-OpenCL-Image
> https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html
J'ai eu un peu de mal à déployer les binaires ROCm 4.3 fournis
par AMD pour Ubuntu dans un environnement de test minimal en
Bullseye. J'ai l'impression qu'il manque des dépendances. Il
m'a fallu un peu de temps pour identifier qu'il me manquait
libtinfo5 sur ma machine par exemple. Astuce : le programme
/opt/rocm-4.3.0/bin/hipconfig, du paquet hip-base, permet
d'obtenir un bilan assez détaillé de ce qu'il peut manquer dans
l'installation, ou ce qui casse.
Bonne journée, :)
--
Étienne Mollier <emol...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.
didier gaumet, on 2021-08-09:
> Je n'ai jamais expérimenté OpenCL, donc mes commentaires sont à prendre avec précaution
>
> De ce que je comprends (de travers?), à l'heure actuelle la seule implémentation d'OpenCL qui prendrait en charge le support des images serait ROCm à partir de la version 3.7 (on en est à 4.3). En tout cas pour de l'AMD/ATI, tu peux utiliser Mesa mais le support des images ne semble pas encore d'actualité.
Je confirme les élucubrations par mes observations…
>
> De ce que je comprends (de travers?), à l'heure actuelle la seule implémentation d'OpenCL qui prendrait en charge le support des images serait ROCm à partir de la version 3.7 (on en est à 4.3). En tout cas pour de l'AMD/ATI, tu peux utiliser Mesa mais le support des images ne semble pas encore d'actualité.
L'implémentation OpenCL 1.2 de Mesa, fournie par le paquet
Debian mesa-opencl-icd, ne prend pas en charge le "Image
support", du moins pas sur ma carte RX560 :
$ clinfo | grep Image
Image support No
Un moyen de tricher est d'utiliser le paquet pocl-opencl-icd ;
c'est la version portable d'OpenCL. Mais bon, l'intérêt est
limité, on ne tourne que sur le processeur, pas sur la puce
d'accélération graphique :
$ clinfo
[…]
Platform Name Portable Computing Language
Number of devices 1
Device Name pthread-AMD Ryzen 5 3600 6-Core Processor
[…]
Image support Yes
Max number of samplers per kernel 16
Max size for 1D images from buffer 1073741824 pixels
Max 1D or 2D image array size 2048 images
Max 2D image size 32768x32768 pixels
Max 3D image size 2048x2048x2048 pixels
Max number of read image args 128
Max number of write image args 128
[…]
Je confirme également que l'implémentation d'OpenCL 2.0 dans
ROCm 4.3 prend en charge le "Image support":
$ /opt/rocm-4.3.0/opencl/bin/clinfo | grep Image
Image support: Yes
J'ignore toutefois si ROCm 4.3 va supporter la puce Vega 8.
> Je n'ai trouvé trace de ROCm dans Debian qu'en version 3.3 de mai 2020 dans le repo experimental donc je suppose que c'est abandonné. Je n'ai trouvé de trace de ROCm dans aucun autre package (mais j'ai peut-être mal cherché)
y encore eu des discussions ces derniers mois sur l'ordre dans
lequel compiler les différents composants. La période de gel a
pas mal ralenti l'ensemble des projets en cours ces sept
derniers mois, et peut-être que l'empaquetage de ROCm en a aussi
fait les frais (ça et la nécessité d'avoir du matériel adéquat à
portée de main : les GPU AMD sont devenus subitement assez rares
de nos jours).
[1] : https://salsa.debian.org/rocm-team
> Tu peux peut-être t'en sortir en installant un paquetage Ubuntu (module ROCm DKMS) à partir des dépôts AMD, ça ne coûte rien de lire leur page de doc.
>
> https://wiki.archlinux.org/title/GPGPU
> https://www.phoronix.com/scan.php?page=news_item&px=ROCm-3.7-OpenCL-Image
> https://rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html
par AMD pour Ubuntu dans un environnement de test minimal en
Bullseye. J'ai l'impression qu'il manque des dépendances. Il
m'a fallu un peu de temps pour identifier qu'il me manquait
libtinfo5 sur ma machine par exemple. Astuce : le programme
/opt/rocm-4.3.0/bin/hipconfig, du paquet hip-base, permet
d'obtenir un bilan assez détaillé de ce qu'il peut manquer dans
l'installation, ou ce qui casse.
Bonne journée, :)
--
Étienne Mollier <emol...@emlwks999.eu>
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.
didier gaumet
Aug 11, 2021, 4:10:03 AM8/11/21
to
Le mardi 10 août 2021 à 21:48 +0200, Étienne Mollier a écrit :
[...]
> Un moyen de tricher est d'utiliser le paquet pocl-opencl-icd
[...]
il y aurait certains cas où pocl ne gère pas que les CPU:
ça ne te concerne pas personnellement (GPU) mais ça pourrait intéresser ceux équipés d'APU (CPU+GPU intégrés) AMD: il semble que certains d'entre eux soient gérés via HSA, auquel cas la partie graphique du chipset serait utilisée:
http://portablecl.org/docs/html/hsa.html
Ceci dit la doc semble vieille de 5 ans et parle d'état relativement expérimental...
benoit
Aug 12, 2021, 12:30:03 PM8/12/21
to
Le mardi 10 août 2021 à 21:48, Étienne Mollier <emol...@emlwks999.eu> a écrit :
> Bonjour Benoît, Bonjour Didier,
Bonjour à toutes et tous;
> Effectivement, les travaux d'empaquetage sont en cours [1]. Il
>
> y encore eu des discussions ces derniers mois sur l'ordre dans
>
> lequel compiler les différents composants. La période de gel a
>
> pas mal ralenti l'ensemble des projets en cours ces sept
>
> derniers mois, et peut-être que l'empaquetage de ROCm en a aussi
>
> fait les frais (ça et la nécessité d'avoir du matériel adéquat à
>
> portée de main : les GPU AMD sont devenus subitement assez rares
>
> de nos jours).
>
> [1] : https://salsa.debian.org/rocm-team
Vu qu'une version plus récente de ROCm (que la 3.3.0 en expérimental)
est en cours d'empaquetage, je vais attendre de l'avoir en sid.
L'activation du support d'OpenCL est une optimisation, Darktable peut
fonctionner sans.
https://darktable.gitlab.io/doc/fr/darktable_and_opencl.html
Un tout grand merci pour vos réponses.
--
Benoit
> Bonjour Benoît, Bonjour Didier,
Bonjour à toutes et tous;
> Effectivement, les travaux d'empaquetage sont en cours [1]. Il
>
> y encore eu des discussions ces derniers mois sur l'ordre dans
>
> lequel compiler les différents composants. La période de gel a
>
> pas mal ralenti l'ensemble des projets en cours ces sept
>
> derniers mois, et peut-être que l'empaquetage de ROCm en a aussi
>
> fait les frais (ça et la nécessité d'avoir du matériel adéquat à
>
> portée de main : les GPU AMD sont devenus subitement assez rares
>
> de nos jours).
>
> [1] : https://salsa.debian.org/rocm-team
est en cours d'empaquetage, je vais attendre de l'avoir en sid.
L'activation du support d'OpenCL est une optimisation, Darktable peut
fonctionner sans.
https://darktable.gitlab.io/doc/fr/darktable_and_opencl.html
Un tout grand merci pour vos réponses.
--
Benoit
didier gaumet
Aug 12, 2021, 1:50:03 PM8/12/21
to
Le jeudi 12 août 2021 à 18:30:03 UTC+2, benoit a écrit :
[...]
(Si quelqu'un s'y connaît suffisamment pour rectifier mes probables erreurs, qu'il le fasse, merci)
Normalement, si tout est correctement paramétré dans ta Debian, je pense que tu dois déjà bénéficier d'OpenCL 1.2 avec l'ICD MESA.
Cela doit, je suppose (je n'ai pas vérifié) permettre aux programmes appelants (ici Darktable) des traitements sur des *éléments* d'image (pixels, vecteurs,...traités directement comme tels ou comme données brutes).
Par contre cela ne te permet pas des traitements sur une image globale. Exemple: je suppose que si tu veux augmenter la luminosité d'une image de 20%, avec OpenCL>=2.0 ce doit être possible en une seule opération dans le code de Darktable. Avec OpenCL<2.0, je suppose que tu dois si tu veux faire la même chose, le code de Darktable doit augmenter de 20% la luminosité de chaque pixel séparément. Pour l'utilisateur c'est transparent, dans les deux cas la manipulation est identique.
Donc avec OpenCL1.2 (MESA), tu dois déjà avoir une accélération du traitement comparé à celui-ci sans OpenCL. Mais avec OpenCL2.2(ROCm) ce doit être encore accéléré par rapport à OpenCL1.2 dans la mesure où, et ça semble le cas, le code Darktable est capable de gérer directement des images et pas seulement les constituantes de celles-ci.
les spécifications de l'API OpenCL 2.2 sont là:
https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/OpenCL_C.pdf
(regarder à 6.1.3 pour les formats d'image introduits avec OpenCL 2.0)
[...]
> L'activation du support d'OpenCL est une optimisation, Darktable peut
> fonctionner sans.
> https://darktable.gitlab.io/doc/fr/darktable_and_opencl.html
[...]
> fonctionner sans.
> https://darktable.gitlab.io/doc/fr/darktable_and_opencl.html
(Si quelqu'un s'y connaît suffisamment pour rectifier mes probables erreurs, qu'il le fasse, merci)
Normalement, si tout est correctement paramétré dans ta Debian, je pense que tu dois déjà bénéficier d'OpenCL 1.2 avec l'ICD MESA.
Cela doit, je suppose (je n'ai pas vérifié) permettre aux programmes appelants (ici Darktable) des traitements sur des *éléments* d'image (pixels, vecteurs,...traités directement comme tels ou comme données brutes).
Par contre cela ne te permet pas des traitements sur une image globale. Exemple: je suppose que si tu veux augmenter la luminosité d'une image de 20%, avec OpenCL>=2.0 ce doit être possible en une seule opération dans le code de Darktable. Avec OpenCL<2.0, je suppose que tu dois si tu veux faire la même chose, le code de Darktable doit augmenter de 20% la luminosité de chaque pixel séparément. Pour l'utilisateur c'est transparent, dans les deux cas la manipulation est identique.
Donc avec OpenCL1.2 (MESA), tu dois déjà avoir une accélération du traitement comparé à celui-ci sans OpenCL. Mais avec OpenCL2.2(ROCm) ce doit être encore accéléré par rapport à OpenCL1.2 dans la mesure où, et ça semble le cas, le code Darktable est capable de gérer directement des images et pas seulement les constituantes de celles-ci.
les spécifications de l'API OpenCL 2.2 sont là:
https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/OpenCL_C.pdf
(regarder à 6.1.3 pour les formats d'image introduits avec OpenCL 2.0)
0 new messages