Ces dernières années, en même temps que les cartes graphiques AMD restaient compétitives, les pilotes pour ces cartes sont devenus les meilleurs pilotes graphiques sous Linux sur quasiment tous les aspects (fiabilité, performance, stabilité, intégration…), sauf pour un usage pour lesquels les pilotes Linux sont un naufrage : le calcul sur carte graphique avec OpenCL.
Sommaire
- Les pilotes AMD sont excellents pour Vulkan, OpenGL, VA-API…
- Les pilotes OpenCL AMD sous Linux n’ont jamais été en aussi mauvaise posture
- Mon initiative I ♥ Compute! pour maintenir scripts et bidouilles, documentation et suivi
- Don de matériel ? Financement ? Prestations professionnelles ?
- Le mot de la fin
Cartes graphiques au banc d’essai
Les pilotes AMD sont excellents pour Vulkan, OpenGL, VA-API…
Sur le plan graphique, la prise en charge d’OpenGL par le pilote libre radeonsi de Mesa est excellent depuis longtemps. Ça fait plusieurs années que le pilote libre est recommandé à la place du pilote propriétaire. La version 4.6 et la plupart des extensions sont implémentées depuis un bon moment maintenant, et le pilote prend même désormais en charge les versions récentes d’OpenGL avec le compatibility profile qui furent longtemps une spécificité du pilote propriétaire et qui était une fonctionnalité spécifique à certains besoins industriels.
Du côté de Vulkan, la nouvelle API graphique plus bas niveau, le pilote libre RADV de Mesa fonctionne très bien, et le pilote libre AMDVLK de AMD fonctionne très bien aussi. Il est même possible d’installer les deux et de choisir le plus performant pour tel ou tel cas d’usage avec une simple variable d’environnement. Il existe en fait même un troisième pilote qui est la variante amdgpu-pro du pilote AMDVLK qui peut parfois apporter certaines fonctionnalités avant les autres. En d’autres termes, l’utilisateur de carte AMD a l’embarras du choix, et ils sont tous bons.
Sur le plan de l’accélération du décodage et du codage de vidéo en utilisant la carte graphique, les APIs VDPAU et VA-API sont très bien prises en charge.
Grâce à la plateforme amdgpu, tous ces pilotes peuvent cohabiter.
Le pilote amdgpu de Linux est globalement très bon, je connais quelques cas spécifiques où ça pourrait être meilleur, mais pour l’écrasante majorité des utilisateurs, tout cela marche très bien. De plus ce pilote noyau amdgpu, et les pilotes radeonsi, radv, vdpau et va-api sont intégrés dans les distributions sans nécessiter de dépôt tiers. Toutes ces fonctionnalités sont à portée d’installation via les paquets officiels de la distribution, quand ces paquets ne sont pas déjà installés par défaut.
Mais il reste un domaine dans lequel la qualité des pilotes AMD n’est pas au rendez-vous, et est même désastreuse : le calcul avec l’API OpenCL.
OpenCL est utilisable par certaines applications comme Darktable (développement photo numérique), Blender (modélisation et rendu 3D), LuxRender (moteur de rendu 3D par lancer de rayon), DaVinci Resolve (montage vidéo), Natron (Compositeur vidéo), et même GIMP (dessin et traitement d’image 2D) et LibreOffice Calc (tableur), et d’autres.
La plupart du temps, ces applications peuvent se passer d’OpenCL, mais le gain de performance apporté par OpenCL est très appréciable, que ce soit en distribuant le calcul entre le CPU et le GPU au lieu de reposer sur le CPU seul, ou en exploitant un GPU qui serait plus performant qu’un CPU pour un type de tâche donnée.
Les pilotes OpenCL AMD sous Linux n’ont jamais été en aussi mauvaise posture
L’état d’OpenCL pour les GPUs AMD sous Linux est maintenant pire que ce qu’il était à l’époque de fglrx (jusqu’à 2015).
Il existe une multitude de pilotes OpenCL pour AMD, visant telle ou telle architecture et la cohabitation est parfois difficile. Parfois les pilotes ne peuvent fonctionner si une autre carte d’une autre génération est branchée, parfois des pilotes différents pour des cartes différentes essaient de s’installer en utilisant les mêmes noms de fichiers.
- La dernière version d’AMD OpenCL PAL pour la génération GCN 5 et suivants date du 29 septembre 2020. Les récentes versions du pilote propriétaire AMDGPU-PRO ne prennent plus en charge OpenCL pour les cartes GCN 5.
- La dernière version d’AMD OpenCL Orca (« Legacy ») pour GCN 1, 2, et 3 datent du 21 juin 2021. Les récentes versions du pilote propriétaire AMDGPU-PRO ne prennent plus en charge OpenCL pour ces cartes. Je ne sais pas si c’est une erreur, car ce pilote est toujours fourni mais ne prend pas en charge GCN 1, 2 et 3 (et je n’ai pas de GCN 4 pour tester).
- ROCm n’est pas pour les utilisateurs ordinaires, il semble développé pour des utilisations industrielles spécifiques, il ne prend pas en charge les applications graphiques (AMD a dit que c’était temporaire mais cela peut durer longtemps) et ne prend en charge qu’une très petite quantité de matériel : une infime sélection de cartes graphiques PCIe et aucune carte graphique intégrée dans les APU AMDs.
Ce pilote ROCm peut même reconnaître certains matériels, tenter de faire quelque chose et déstabiliser le noyau de telle sorte que les utilisateurs sont invités à redémarrer leur machine.
Le pilote ROCm a remplacé le pilote PAL sans être une alternative, ni dans le but, ni dans la prise en charge matérielle, ni dans l’implémentation, ni dans sa capacité à répondre aux besoins.
ROCm déprécie très rapidement le matériel. L’architecture GCN 2 n’a fonctionné que quelque mois il y a des années, et l’architecture GCN 4 (Polaris) est rapportée comme ayant cessé de fonctionner il y a quelque temps (seulement deux étaient alors prises en charge). Actuellement il est dit que seulement trois puces sont prises en charge par ROCm (Vega 10, Vega 7nm, MI1000).
Du côté de la communauté, Clover fonctionne pour certains usages (exemple : LuxRender) mais pas pour d’autres (exemple : Darktable) puisque le traitement d’image n’est pas encore implémenté. Avec Clover LuxMark est deux fois plus rapide qu’Orca et ROCm sur GCN (probablement aussi avec PAL).
Malheureusement j’ai remarqué que Clover est devenu cassé au cours des dernières années. La dernière version précompilée pour Ubuntu que j’ai trouvée et qui fonctionne date de 2019. J’ai écrit un script pour compiler la dernière version de Clover avec la dernière version de LLVM et je peux confirmer que c’est cassé en amont. Ah, et pour les dernières versions fonctionnelles, elles ont perdu entre 15 et 20% en performance par rapport à 2018.
Clover est d’ailleurs le seul pilote existant fonctionnant avec les cartes graphiques TeraScale 2 et 3 (et une paire de TeraScale 1 pourraient théoriquement être implémentées mais ce n’est pas fait), car le dernier pilote officiel AMD pour ces cartes était Radeon Software (fglrx). Il est abandonné depuis de très nombreuses années (dernière version en 2015, et celui pour TeraScale 1 datent de 2013) et est incompatible avec la plateforme amdgpu et les noyaux récents.
En parlant de fglrx, j’ai vu ces dernières années des personnes rapporter qu’ils utilisaient encore fglrx (et donc des environnements de 2015) pour utiliser OpenCL avec du matériel GCN, c’est aussi pourquoi j’ai souvent conseillé mes scripts pour aider ces personnes à mettre à jour leurs systèmes.
Mon initiative I ♥ Compute! pour maintenir scripts et bidouilles, documentation et suivi
J’ai un grand intérêt dans OpenCL parce que j’utilise beaucoup Darktable (logiciel de développement photographique), et pour cela, depuis des années, je maintiens des scripts et des bidouilles pour conserver cette fonctionnalité, pour mon usage d’abord, et que je partage ensuite avec qui en a besoin.
Au fil des années, j’ai écrit et réécrit plein de scripts. Et puis j’ai commencé à ressentir le besoin de tracer au même endroit les tickets que j’ouvrais à droite et à gauche. J’ai donc ouvert un dépôt sur GitLab que j’ai appelé « I ♥ Compute! » pour y conserver ma documentation, mes scripts, et avoir un gestionnaire de ticket unifié.
La dernière version de mon script pour Ubuntu (marche peut-être ou partiellement avec Debian) permet d’installer sur Ubuntu 20.04 LTS et Ubuntu 21.10, et simultanément :
- La dernière version fonctionnelle d’AMD OpenCL Orca (ancienne archive AMDGPU-PRO) ;
- La dernière version fonctionnelle d’AMD OpenCL PAL (ancienne archive AMDGPU-PRO) ;
- La dernière version d’AMD ROCm (dépôt AMD) ;
- La dernière version fonctionnelle de Mesa Clover (dépôt Ubuntu) ;
- La dernière version identifiée de la platforme AMD APP pour CPUs (ancienne archive Radeon Software de l’ère fglrx).
Le dernier pilote est seulement la partie CPU qui était fournie avec fglrx et qui permet à un logiciel OpenCL de répartir des tâches OpenCL à la fois sur le CPU et le GPU pour exploiter tout le matériel disponible. La partie GPU de fglrx est inutilisable aujourd’hui de toute façon.
Il faut savoir que certains pilotes ont des bugs. Par exemple, la dernière version fonctionnelle d’Orca devient inutilisable s’il existe une seule carte utilisant le pilote radeon (au lieu d’amdgpu) dans le système, ainsi si vous avez une carte pilotée par radeon et une autre pilotée par amdgpu, Orca ne fonctionnera pas avec celle pilotée par amdgpu à cause de la présence de l’autre, alors que ça marcherait si l’autre est enlevée physiquement du système.
Comme je l’ai écrit plus haut, ROCm peut mettre en vrac le noyau s’il essaie de piloter certaines cartes GCN, donc si votre système a une carte GCN affectée comme une R9 390X et une autre carte plus récente comme une Vega et que vous installez ROCm pour prendre en charge la Vega, vous aurez des problèmes. Ah et j’ai pu constater que toutes les Vegas (y compris des cartes PCIe) ne fonctionnent pas avec ROCm (j’ai dû utiliser PAL une fois). Certaines sont prises en charge par PAL mais PAL a été retiré. Je vous avais déjà dit que c’était galère ?
Il y a actuellement un script pour installer les pilotes OpenCL AMD sur Ubuntu, un script pour compiler Clover soi-même, et un script pour compiler clvk (un projet d’implémentation d’OpenCL sur Vulkan), mais à l’heure actuelle aucun de ces deux-là ne marche (même si Clover a partiellement fonctionné dans le passé).
Mes scripts viennent avec une aide intégrée (--help).
Vous trouverez donc un condensé de mes connaissances sur le dépôt I ♥ Compute! sur GitLab.
Ça ne traite pas que d’AMD mais la situation d’AMD est la pire de toutes. Les pilotes (certes propriétaires et non intégrés) de Nvidia prennent généralement en charge OpenCL et les pilotes Intel commencent à être pas trop mal (même si là aussi, c’est la prolifération des pilotes, ça me semble moins mauvais).
Vous y trouverez donc également des scripts. Je préviens que je n’ai pas les moyens de maintenir la compatibilité antérieure. Si vous utilisez un de mes scripts pour installer un pilote, assurez-vous de conserver quelque part le script en question dans la version que vous avez utilisée, pour que vous puissiez désinstaller la version que vous avez installée. Je n’ai pas les moyens de m’assurer que les nouvelles versions des scripts désinstallent ce qui a été installé avec une ancienne version.
Et vous y trouverez également un espace de suivi où je trace au même endroit les problèmes que je rencontre et que je rapporte ailleurs (ou qui n’ont parfois pas d’endroit pour être rapportés).
Don de matériel ? Financement ? Prestations professionnelles ?
Je ne teste d’ailleurs pas que les cartes AMD, même si c’est ma priorité (parce que c’est ce que j’utilise).
Du côté AMD je possède déjà des cartes TeraScale 1 (AGP, PCI, PCIe),
TeraScale 2 (PCIe),TeraScale 3 (PCIe), GCN 1 (PCIe), GCN 2 (PCIe), GCN 3 (integrée), et GCN 5 (integrée). J’ai aussi les cartes-mères qui vont avec (AGP, PCIe 2, 3, 4).
Je n’ai pas de carte AMD GCN 4 (Polaris), RDNA1/CDNA1 (Navi), RDNA2/CDNA2 (Big Navi) et en particulier pas de matériel AMD pris en charge par ROCr. Des cartes non-intégrées GCN 3 et GCN 5 seraient utiles aussi (celles qui sont embarquées dans des APUs peuvent avoir leur propre limitations spécifiques).
Plus de détails sur le matériel que je possède et les instructions pour les dons de matériel éventuels sont référencés là.
En particulier j’ai besoin d’une carte GCN 4 pour tester si la dernière version de Orca qui ne gère plus GCN 1, 2 et 3 gère tout de même GCN 4 (autrement AMD la distribuerait pour rien).
Ce matériel fait partie de celui que j’utilise pour tester et valider le jeu Unvanquished, avec ce genre de tableau (ici pour OpenGL). Il serait utile d’avoir un tel tableau pour OpenCL mais c’est beaucoup de travail.
Pendant toutes ces années j’ai fourni ces scripts OpenCL et mes conseils autour de moi, mais alors que la situation devient plus mauvaise, je me suis dit que c’était une bonne idée de proposer la capacité de faire des dons (matériel et financier). Comme je suis actuellement à mon compte, le cas échéant je pourrai affecter plus de temps à cette initiative si je reçois quelques dons financiers. J’ai donc ajouté des liens pour faire des dons sur la page.
Et vu que j’ai mon entreprise, certains seront peut-être intéressés par des prestations spécifiques ? Par exemple dans le passé et dans un cadre professionnel j’avais écrit un script pour installer le pilote AMD OpenCL PAL sur Mageia pour piloter une carte Vega afin d’accélérer Blender. Je n’ai pas du tout les moyens de maintenir ce genre de script, mais il y a peut-être un besoin.
J’ai donc ajouté sur mon site professionnel que je propose mes services pour faire marcher OpenCL avec AMD pour des clients professionnels.
Le mot de la fin
Pour résumer, sans utiliser des logiciels obsolètes qu’AMD ne soutient plus et n’inclut plus dans sa suite de pilotes, l’état actuel de la fourniture OpenCL avec le matériel AMD sous Linux semble être ROCm dont la documentation ne liste que trois puces officiellement considérées et il est dit que les applications graphiques ne sont pas prises en charge.
Il y a quelques tentatives de faire tourner OpenCL sur Vulkan, comme clvk qui repose sur clspv, peut-être que c’est ça l’avenir ? Pour le moment ça ne marche pas encore en tout cas.
AMD devrait peut-être s’inquiéter de la tentative d’Intel de sortir des cartes PCI express tout en ayant une prise en charge d’OpenCL entièrement libre et intégrée dans les dépôts.
Si AMD a besoin d’aide, a priori je sais faire cohabiter leurs pilotes…
Et vous, quelle est votre expérience avec OpenCL, Linux et AMD ?
# OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 6. Dernière modification le 01 février 2022 à 11:55.
Je développe en CUDA depuis presque le début, vers 2009-2010, et je me suis intéressé aussi à OpenCL, pour l'aspect portabilité en plus, mais j'ai fait face à beaucoup de problèmes de drivers, de performance, etc, et je suis finalement resté sur CUDA (je sais Nvidia pas bien, pas libre, etc, mais ça marche, il y a plein d'outils qui fonctionnent très bien, et c'est ce qui est installé sur les machines auxquelles j'ai accès).
Suite à mes déboires, j'avais recherché un peu d'autres expériences sur le sujet et je suis tombé sur cette présentation qui résume bien les problèmes avec OpenCL : l'API est libre, ok, les implantations peuvent l'être, ok, mais chaque implanteur est aussi libre d'interpréter certains aspects de la spec comme il l'entend, de ne supporter qu'une version de l'API (Nvidia reste en 1.2 il me semble) et évidemment d'introduire ses propres bugs. Donc la portabilité annoncée, c'est pas garantie.
Une erreur toute bête à mes débuts sur laquelle j'étais tombé entre Intel et Nvidia, je précise que c'est de ma faute, j'étais pressé : les fonctions OpenCL retournent un code erreur sous la forme d'un int : cl_int err = clMaFonctionOpenCL(…), et pour traiter l'erreur j'ai supposé que, comme d'habitude, 0 c'était ok, donc if( err ) {// je traite l'erreur}. Mais rien ne précise la valeur dans la spec, donc un des 2 vendeurs a choisi une autre valeur que 0 quand tout va bien donc il faut faire explicitement if( err != CL_SUCCESS ) {…}.
Ce n'est pas grand chose, mais ça ajoute à la verbosité d'OpenCL.
Heureusement SYCL est là pour résoudre tous ces problèmes… ou pas…
Personnellement, je ne comprends pas l'acharnement à faire vouloir mettre une API portable partout alors que pour avoir les performances il faut de toute façon réécrire des kernels optimisés pour presque chaque architecture.
[^] # Re: OpenCL, portabilité et performance en général
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Il manque une suite de teste complète ?
"La première sécurité est la liberté"
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 2.
Il y a une suite de tests appelée CTS mais qui semble être arrivée un peu tard.
[^] # Re: OpenCL, portabilité et performance en général
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
si tu as le temps, tu pourrais tenter de trouver les combinaisons HW/SW qui passent le test ?
"La première sécurité est la liberté"
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 2.
Il y a une liste chez Khronos, sinon pour ma part j'ai abandonné OpenCL il y a déjà un petit moment. Je regarde plutôt SYCL et oneAPI avec le compilo DPCPP, mais j'attends aussi les prochains GPU Intel pour voir si ça amène enfin un peu de concurrence. Il me semble quand même difficile pour Intel de revenir au niveau de Nvidia qui a du matériel à tous les étages et des softs bien éprouvés. AMD aussi a du matériel dans les cartons mais c'est toujours au niveau bibliothèques et outils qu'il y a un gros manque.
[^] # Re: OpenCL, portabilité et performance en général
Posté par abriotde . Évalué à 5.
Oui et non. C'est normal de faire en sorte d'être le plus générique possible et c'est certains que le plus optimal possible sera toujours l'assembleur… mais heureusement aujourd'hui coder en assembleur n'a que très rarement du sens.
En pratique, il y a toujours des choses a réécrire pour gagner un peu en optimisation mais il y a aussi un compromis a trouver entre optimisation et rentabilité.
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 3.
Je suis pas tout à fait d'accord. Une question que je me pose depuis l'annonce d'OpenCL c'est à qui ça se destine. Je travaille sur des codes écrits généralement par des spécialistes de leurs domaines mais pas des informaticiens donc les codes fonctionnent (Fortran, C voir C++), mais ne sont pas optimisés. Ces personnes là font aussi un peu du MPI mais généralement synchrone, et de l'OpenMP, peut être un peu de CUDA, mais ne font pas d'OpenCL. Ceux qui optimisent vont généralement utiliser des technos ad-hoc : des intrinsics pour la vecto, peut être de l'assembleur (quand le compilo n'y arrive pas), du CUDA bien optimisé, etc, mais peu d'OpenCL (sauf pour les archis qui ne supportent que ça) car c'est verbeux, ça oblige à écrire un code optimisé par architecture et pour la portabilité, souvent on ne tourne que sur 1 ou 2 architectures (dans mon domaine au moins).
Concernant les gains en optimisant pour son architecture, c'est généralement pas marginal du tout, même sur des codes très simples et sans descendre au niveau assembleur. Il suffit de prendre une simple réduction pour s'en convaincre, écrite "naïvement" on est assez loin de la bande passante disponible. Un peu d'intrinsics, plusieurs variables temporaires pour accumuler et profiter du pipeline des unités de calcul, des "mov" non temporels si on ne réutilise pas les données ensuite, et le code est tout de suite beaucoup moins lisible mais beaucoup plus rapide. Et pour CUDA je vous laisse réfléchir aux optimisations proposées par M. Harris et à la tête du code final.
Donc la promesse d'OpenCL (en fait pas vraiment d'OpenCL, c'est plutôt ce que beaucoup pensent d'OpenCL) d'écrire un seul code qui passe pas trop mal partout avec des perfs (80% des perfs?) me semble illusoire.
Concernant la rentabilité, ceux qui ont investi dans CUDA il y a 10 ans s'en sortent à mon avis pas mal. Par contre OpenCL, on voit bien le déclin des drivers, du support par les fabricants, de l'utilisation dans des applis comme Blender, etc. Et je pense que SYCL ne résoudra pas non plus le problème. Si on veut des perfs il faut du code spécifique. Après, on peut toujours croire aux compilateurs "automagiques" qui vont automatiquement transformer les structures de données du code, vectoriser, faire les "mov" non temporels quand il faut, dérouler et casser les dépendances correctement, etc. Mais, je pense avoir encore pas mal de boulot pour des années !
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . Évalué à 2. Dernière modification le 01 février 2022 à 20:32.
Ca c'est parce que tu sous-estimes le travail sur le backend llvm amdgpu kappa
P.S. je fais mon intéressant, en vérité j'en sais rien, sauf que tout le monde m'en dit des merveilles.
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 4.
J'ai pas regardé, comme peu de personnes… en fait personne n'utilise des GPU AMD dans mon entourage ! Mais c'est un point un peu rageant de savoir que les GPU AMD sur le papier ont des specs très intéressantes mais qu'on est toujours bloqué par un driver qui est pas stable, une install qui passe pas, une API pas très pratique, pas beaucoup de doc, ou des libs qui n'existent pas.
Avec un matériel comparable, mais en offrant du soft qui répond aux besoins, Nvidia a réussi a prendre le marché du calcul sur GPU. J'ai commencé, sur des GTX 285, c'était pas très stable mais on pouvait tester et rapidement c'est devenu bien stable. Sur des GTX 480 dans un serveur, j'ai fait des TP CUDA avec une trentaine d'étudiants sans que ça bronche.
En plus Nvidia proposait un partenariat académique Nvidia Teaching Center et m'a envoyé des dizaines de cartes gratuitement (bon d'accord à l'époque ils ne savaient pas quoi faire de leur stock de GTX 480 et ça permettait de chauffer les salles l'hiver) et même une Tesla, et des bouquins pour les étudiants. Il y a aussi plein de webinaires, des exemples, des ressources. Intel, AMD et ARM n'ont pas mis en place de partenariat similaire, c'est sans doute aussi ce positionnement qui a pas mal aidé à l'installation de CUDA.
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . Évalué à 5.
Oui, niveau intégration, documentation et lobbying Nvidia n'a pas son pareil.
A l'époque où NVidia a lancé à pleine vapeur CUDA, AMD commençait à peine la R&D HSA, avec un compilateur maison, une représentation intermédiaire HSAIL maison, une cible de compilation universelle GPU FPGA DSP… Ca n'a pas marché, je ne sais pas pourquoi, et AMD s'est depuis rabattu sur de la compilation "GPU classique": avec un backend LLVM qui cible les GPUs uniquement - backend complètement ouvert.
Donc AMD a dix ans de retard sur le "compute"/GPGPU. Et pas de super moyens investis pour mettre ROCm à disposition du grand public et toujours une énorme focalisation sur les superordinateurs, ANL, LNLL, El Capitan/Frontier…
Puis il y a une scission entre deux pilotes noyaux au sein du même module amdgpu, qui persiste encore aujourd'hui, ce qui ne facilite pas les choses.
Ce que j'ai chiné comme info ces dernières semaines d'investigation^
[^] # Re: OpenCL, portabilité et performance en général
Posté par Anthony Jaguenaud . Évalué à 2.
Ça me fait penser à une question… sur mon ordi, j’ai un Ryzen avec un APU (sans écran), et une carte graphique Nvidia, peut-on faire de l’openCL sur l’APU ?
Peut-on utiliser le back-end amdgpu de llvm ?
[^] # Re: OpenCL, portabilité et performance en général
Posté par Maxzor . Évalué à 2.
oui! mais la route est longue…
https://www.reddit.com/r/Amd/comments/rd7mmi/heres_something_you_dont_see_every_day_pytorch/
[^] # Re: OpenCL, portabilité et performance en général
Posté par sjub . Évalué à 2.
Je ne connais pas les paquets spécifiques à installer mais c'est possible !
L'outil
clinfopermet de lister les "plateforms" et "devices" disponibles sur la machine.[^] # Re: OpenCL, portabilité et performance en général
Posté par Anthony Jaguenaud . Évalué à 2.
Merci, bon il ne me détecte que ma Mi1080… il y a quelque chose à installer pour activer l'APU ?
[^] # Re: OpenCL, portabilité et performance en général
Posté par Anthony Jaguenaud . Évalué à 2.
Ah, après vérification, je n'ai pas d'APU… </me sifflote en prenant la porte>
[^] # Re: OpenCL, portabilité et performance en général
Posté par Thomas Debesse (site web personnel) . Évalué à 10. Dernière modification le 02 février 2022 à 01:14.
En fait je crois que c’est là le nœud du problème.
Il me semble qu’il y a deux types d’utilisateurs :
Les premiers sont aussi les seuls utilisateurs de leur logiciel. Ils choisissent une matériel, ils choisissent un environnement logiciels, et ils développent une solution. Ceux-là n’ont pas vraiment de problèmes. À la base ils n’ont pas vraiment de problème de portabilité. Et on voit bien que ROCm vise ce genre de client. Même si ROCm ne prenait en charge qu’une seule carte par génération de 3 ans, ça répondrait au besoin.
Une entreprise a des besoins en calcul pour un problème donné ? Hop, elle achète 200 cartes du modèle recommandé, prend la bibliothèque qui va bien, envoie ses gars au turbin et voilà.
Il y a clairement un marché du calcul sur GPU pour faire des trucs très complexe dans des fermes de calcul où l’on trait la dernière goûte de puissance sur un matériel préconisé avec un pilote fournit par le fabriquant du matériel sur une distro qui a deux ans.
Il y a plein de trucs dans ROCm qui n’ont d’ailleurs rien à voir avec OpenCL. C’est probablement pour ce besoin-là.
Peut-être qu’AMD répond déjà parfaitement à ce besoin, je ne sais pas.
Les seconds ne maîtrisent pas toute la chaîne, ils sont fournisseurs, ils sont clients, ils sont intermédiaires.
En tant qu’utilisateur de Darktable, je ne suis pas développeur OpenCL. Le développeur de Dartkable, lui, n’a pas pour objectif de répondre à mon petit cas particulier de la puce graphique intégrée dans l’ordinateur portable que j’achète pour des raisons de taille et de poids (et de présence de trackpoint) ou la carte graphique que j’achète parce que, mettons, je suis tombé sur une bonne affaire.
Les développeurs comme les utilisateurs de logiciels comme Darktable, Blender ou DaVinci Resolve ou Natron aimeraient bien pouvoir simplement fournir et se faire fournir des logiciels qui exploitent leur matériel, même si ce n’est qu’à 80%.
Et c’est là que c’est la misère.
Je ne doute pas qu’OpenCL n’est pas parfait, qu’il faille parfois faire des adaptations ne m’étonne pas. Mais il y a un vrai besoin d’une API dont 95% du code est commun et fonctionne pour 95% des utilisateurs même si ça n’exploite pas 95% des performances.
Pour prendre exemple avec OpenGL que je connais mieux, je sais que la façon de mettre en œuvre OpenGL dans un programme est spécifique à chaque système d’exploitation (j’ai dû implémenter le partage de contexte dans GtkGLExt pour GTK2 sur macOS pour porter NetRadiant sur macOS). Je sais aussi qu’on peut rencontrer des bugs qui sont spécifiques à un fabriquant ou un pilote (récemment dans Unvanquished il a fallu réimplémenter un calcul d’une manière différente pour contourner un bug du pilote Nvidia).
Si OpenCL est aussi chiant, ça reste acceptable. Au final on peut quand même viser les trois OS principaux et la quasi totalité des utilisateurs moyennant quelques adaptations et des rustines.
Est-ce que l’avenir de Blender c’est CUDA pour Nvidia et un truc spécifique à AMD pour AMD ? Ça ne me pose pas problème s’ils ont les moyens d’implémenter des variantes spécifiques à chaque fabriquant si ça permet d’extraire plus de jus, mais il y a un besoin pour une solution générique (ou quasi générique).
Si un jour OpenCL sur Vulkan fonctionne, ça sera un immense soulagement pour tous ceux qui sont dans la deuxième catégorie : ceux qui veulent faire du développement photo ou du montage vidéo avec un logiciel générique, je me demande même si ça ne pourrait pas réveiller une regain d’intérêt pour OpenCL si magiquement OpenCL marche partout où Vulkan marche…
Pour les entreprises qui fabriquent des fermes de calculs et qui salarient leurs développeurs pour répondre à leurs propres besoins, OpenCL sur Vulkan ne sera d’aucun intérêt.
Il y a deux besoins qui semblent confondus, et ce depuis le début du calcul sur GPU. Il me semble qu’Nvidia a su les identifier et les adresser tout les deux avec CUDA.
Apple a aussi identifié le second besoin, celui du poste de travail (tandis qu’ils ne sont pas vraiment concernés par le premier besoin des fermes de calcul). Pour Apple il est important que les acheteurs de mac aient des logiciels de création qui marchent sur leur mac qu’ils utilisent une puce Nvidia (dans le passé) ou AMD (aujourd’hui), et que les logiciels continuent de marcher à travers les générations de matériel même s’ils ne sont pas mis à jour.
OpenCL c’est aussi ce marché : le marché du créateur, celui qui voudrait s’acheter une gros ThreadRipper avec une grosse RDNA pour faire de la vidéo 4K@60 avec des effets sexy pour son public sur Youtube. Ce même créateur n’est pas concerné par les solutions utilisées par les entreprises et institutions qui font des simulations d’ouragan ou qui minent du duckcoin™.
ce commentaire est sous licence cc by 4 et précédentes
# C'est ma "grande" déception au sujet d'AMD
Posté par xoddark . Évalué à 9.
Je m'intéresse au développement des pilotes libre AMD depuis l'annonce du développement officiel de pilote libre (2009 je crois). J'ai suivi les progrès, les difficultés, les essaie …
Et aujourd'hui on à la confirmation que c'était vraiment une stratégie de long terme et que ça à payer … sauf coté OpenCL.
Et étant utilisateur régulier de Darktable (entre autres) c'est un sujet de déception pour moi. J'avais suivi avec espoir les débuts de Clover pour ensuite me retrouver frustré par l'arrêt de sont développement.
Globalement, je dirais qu'OpenCL est une technologie assez "mal aimée", et donc c'est assez difficile d'avoir des personnes/financement pour du développement de driver libre.
Bravo pour tes efforts, j'espère que ça aidera à recréer une émulsion autour de cette technologie.
Il n'y aurait pas une programmeuse, un programmeur débutant qui serais intéressé par travailler sur Clover pendant le Google summer of Code (ou autre initiative de ce genre) ?
Avec de meilleurs drivers, il serait plus facile d'avoir plus d'application à l'utiliser.
# Très belle initiative
Posté par YBoy360 (site web personnel) . Évalué à 6.
Si ça t’intéresse, j'ai une carte à base de RDNA1 que je peux te donner (tu sais où me trouver) et je vais recevoir une carte RDNA2 que tu pourrais emprunter (d'ici quelques jours).
La RDNA2 est une Gigabyte, c'est pour moi un challenge d'acheter cette marque..
[^] # Re: Très belle initiative
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Héhé oui ça m’intéresse ! :D Je te contacterai dans les jours qui viennent. ;-)
Concernant Gigabyte, j’ai récemment acheté une carte-mère de chez eux et… pour booter un SSD sata sur une carte PCIe il faut activer le boot legacy (BIOS), sauf que le SSD est installé façon UEFI, donc soit j’active UEFI et je peux pas booter car le disque est pas visible, soit j’active BIOS et je peux pas booter car le disque, bien que visible, est installé en UEFI. C’est magique. D’ordinaire sur les cartes mères je vois un mode hybride, permettant aux BIOS des cartes PCIe de démarrer, et au boot UEFI d’accéder aux disques rendus visibles de cette manière. Ça m’a fait tout drôle. :D Bon mais sinon à part ça elle est pas mal, et elle est moins chère que l’équivalente Asus et je n’avais pas besoin de WiFi et la Gigabyte était plus compatible avec mon boîtier).
ce commentaire est sous licence cc by 4 et précédentes
# OpenCL? ROCm?
Posté par Maxzor . Évalué à 7. Dernière modification le 01 février 2022 à 13:49.
J'aide Debian à empaqueter ROCm. J'ai poussé sur le dépôt gitlab Debian de l'équipe une première mouture de l'implémentation OpenCL 2.2 ROCm (avec son ICD): clinfo ne fonctionne pas et un connaisseur de cette API serait le bienvenu!
Il y a bien une équipe dédiée chez Debian, mais pour l'instant ils n'ont pas répondu.
Question qui a l'air de troll mais qui n'en est pas: pourquoi tenez-vous à OpenCL? N'est-il pas plus agréable de programmer en C++ 17 avec HIP(~CUDA)? Oui je ne connais pas grand chose à la programmation GPU, je veux juste que Blender + HIP fonctionne ':)
Personnellement, je suis intéressé par le GSoC, mais plutôt pour l'interop HIP/Mesa Vulkan (RADV) qui est ce que le moteur de rendu Cycles de Blender utilise.
D'accord que le support est beaucoup trop court pour ROCm.
[^] # Re: OpenCL? ROCm?
Posté par E3Ms6vyX . Évalué à 3.
Globalement, pour le calcul scientifique sur GPU, j'ai l'impression que OpenACC / OpenMP / Cuda sont la norme.
[^] # Re: OpenCL? ROCm?
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Je n’ai jamais compilé ROCm moi même, mais une chose que j’ai remarquée, c’est que le
clinfousuellement inclus dans les distributions ne connaît d’OpenCL qu’une version inférieure à celle prise en charge par ROCm, donc c’est un truc à se manger des symboles inconnus et des crashs si on utilise leclinfodu système avec ROCm.Je crois que c’est pour cela que le dépôt ROCm fournit aussi un paquet
clinfoplus récent. Attention, j’ai comme l’impression que leclinfod’AMD n’est pas la même base de code (par exemple ne gère pas les mêmes variables d’environnement il me semble). Quand je dis « plus récent », c’est une version plus récente d’OpenCL.ce commentaire est sous licence cc by 4 et précédentes
# Pou ceux qui aiment les langages de haut niveau ...
Posté par freejeff . Évalué à 6.
J'ai vu quelques discussions sur le naufrage d'OpenCL dans le calcul HPC.
Étant mécanicien, j'ai de vraies difficultés à avoir des doctorants maîtrisant la programmation. J'arrive à avoir des étudiants autonomes en python, mais pour C/C++, le peu de fois que l'on a essayé ça a été la boucherie …
Du coup on a tout de même très souvent des besoins de puissances, même pour des nuls en info comme nous !!
Je trouve que ces dernières années en vrai travail de fond a été fait pour nous pour faire du calcul HPC sans avoir de grosses compétences sur ce sujet !
Le premier point est indiscutablement numba, cette bibliothèque permet de faire de de la compilation JIT, et même de faire de la parallélisation, on peut vite arriver à des performances proches du C/C++, tout en restant en python ! C'est plutôt cool. Mais voilà numba n'a pas de backend OpenCL, il faut croire que plus personne ne croit à OpenCL !
Les scientifiques aiment bien utiliser python comme MATLab avec numpy/scipy/matplotlib/… et NVIDIA le sait ! Ils nous ont fait un super framework appelé RAPIDS ou on peut remplacer numpy par cupy, skimage pour cucim, …
Du coup, il faut très peu de changement pour permettre d'utiliser un code sur GPU. Alors certes, ce n'est pas optimisé, mais on peut facilement avoir des facteurs 100 sur certaines fonctions appelées, franchement ça se prend !
Ils ont tout mis en MIT, donc on a même vu apparaître un back-end ROCm.
Donc certes, leur drivers ne sont pas libres, mais pour le coup, vu à quel point cela change la donne chez nous c'est clairement pas un "Fuck you" mais un "Thank you" pour cette contribution au libre !
J'espère que l'on pourra de plus en plus se servir de ces outils en comprenant les contraintes matérielles, mais sans avoir à gérer les complexités liées à des langages plus orientés dev info.
[^] # Re: Pou ceux qui aiment les langages de haut niveau ...
Posté par Maxzor . Évalué à 2.
C'est clair que Rapids c'est quelque chose!
Il y a un back-end ROCm?!
[^] # Re: Pou ceux qui aiment les langages de haut niveau ...
Posté par freejeff . Évalué à 3.
Non, pas dans Rapids directement, mais déjà dans cupy :
https://docs.cupy.dev/en/v7.8.0/install_rocm.html
Pour le reste, il ne me semble pas qu'il y ait un début de travail de fait …
L'intérêt d'avoir mis tout ça en MIT, c'est que c'est possible de le faire.
Phronix en parlait :
"Pour convertir du code CUDA en exécution sur GPU AMD, l'accent est évidemment mis sur l'utilisation de l'interface hétérogène HIP open-source d'AMD. Avec le Clang "Hipify", les traductions basées sur la source peuvent être réalisées en grande partie à partir de CUDA. Il existe également Hipify-Perl pour la recherche/remplacement basée sur le texte lors de la migration de CUDA vers HIP. Les approches basées sur HIP ont donné de bons résultats avec une surcharge d'environ 2 %. "
Du coup, s'il y a un réel intérêt, ça verra le jour …
En attendant, le travail fait par NVIDIA est remarquable et il justifie totalement sur cet aspect précis un soutien franc et massif.
En espérant qu'AMD investisse à terme dans ce type de dev.
# Sur Fedora
Posté par AlexTérieur . Évalué à 2. Dernière modification le 03 février 2022 à 06:53.
J'avais déjà fait un journal à l'époque et expliquait la difficulté d'avoir l'accélération calcul GPU.
Je voulais faire un suivi mais de l'eau a coulé sous les ponts et je trouve qu'on peut très bien se passer de ce système de calcul, mais bravo pour la dépêche qui est plus fouillée que mon journal et qui met à jour le suivi (et qui confirme que j'ai bien fait de laisser tomber).
Pas bravo pour AMD sur le coup, qui pousse les gens à s'orienter vers CUDA…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sur Fedora
Posté par Maxzor . Évalué à 2.
Jeremy Newton est en train d'empaqueter ROCm pour Fedora.
[^] # Re: Sur Fedora
Posté par AlexTérieur . Évalué à 4. Dernière modification le 03 février 2022 à 20:34.
Tu rigoles peut-être mais beaucoup de projets libres concernant l'imagerie en général s'appuient sur CUDA. Parce que c'est plus facile d'utilisation/déploiement.
Autant j'ai loué l'investissement de AMD ces dernières années concernant les pilotes des GPU, autant j'ai envie de jurer par tous les noms concernant le point sur les calculs GPU.
Ou comment se saborder en si peu.
# Et pour Intel ?
Posté par sjub . Évalué à 3.
Cette news m'a donné envie de laisser une nouvelle chance à OpenCL, au moins de retester quelques bouts de codes qui traînent !
J'avais bricolé avec OpenCL sur mon vieux Broadwell avec du HD Graphics 5300 Gen8 avec Beignet à l'époque, j'ai vu passer l'initiative NEO, mais je ne trouve plus de paquet pour ma Debian, intel-opencl-icd n'est plus dispo, j'ai aussi essayé un obscur intel-oneapi-runtime-opencl sans succès.
J'ai loupé un truc ? Est-ce que vous avez des retours sur Intel et OpenCL plus récents ? Est-ce qu'il faut envisager une autre publi dans la même lignée "OpenCL sous Linux : l'état des pilotes Intel, c'était mieux avant" ?
[^] # Re: Et pour Intel ?
Posté par sjub . Évalué à 1.
Après vérification le intel-oneapi-runtime-opencl c'est pour le CPU :
intel-oneapi-runtime-opencl/all,now 2022.0.2-3658 amd64 [installé]
Intel® CPU Runtime for OpenCL(TM) Applications runtime
# En dehors du côté pratique pour se chauffer l'hiver, en programmation FPGA?
Posté par tao popus . Évalué à 3.
OpenCL est un des langage pouvant être utilisé, en plus des Verilog, VHDL (et autres HDL et variantes) pour programmer les FPGA. Quelqu'un a-t il déjà pratiqué, et quels sont les avantages par rapport aux HDL ?
Design space exploration of multi-core RTL via high level synthesis from OpenCL models
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.