URL: https://linuxfr.org/news/opencl-sous-linux-l-etat-des-drivers-amd-est-desormais-pire-que-ce-qu-il-etait-a-l-epoque-de-fglrx Title: OpenCL sous Linux : l’état des drivers AMD est désormais pire que ce qu’il était à l’époque de fglrx Authors: Thomas Debesse vmagnin, alkino et Maxzor Date: 2022-01-25T19:44:33+01:00 License: CC By-SA Tags: Score: 6 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. ---- [Dépôt I ♥ Compute!](https://gitlab.com/illwieckz/i-love-compute) [OpenCL on Linux: state of AMD drivers is now worse than it was back in the days of fglrx](https://rebuild.sh/post/2022-01-25-OpenCL_on_Linux_state_of_AMD_drivers_is_now_worse_than_it_was_back_in_the_days_of_fglrx/) ---- [![test de cartes graphiques](https://illwieckz.net/media/reduc/20220125.test-carte-graphiques.thomas-debesse/20220125-010849-000.test-carte-graphiques.thomas-debesse.720.jpg)](https://illwieckz.net/media/image/20220125.test-carte-graphiques.thomas-debesse/20220125-010849-000.test-carte-graphiques.thomas-debesse.jpg) _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](https://en.wikipedia.org/wiki/ROCm#OpenCL) 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](https://github.com/RadeonOpenCompute/ROCm/issues/1397) (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](https://github.com/RadeonOpenCompute/ROCm/issues/1624) 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](https://github.com/RadeonOpenCompute/ROCm/blob/c3f91afb2688deb638c360497e35b249f8026667/README.md#hardware-and-software-support) 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%](https://gitlab.com/illwieckz/i-love-compute/-/issues/17) 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 ![I ♥ Compute!](https://dl.illwieckz.net/b/i-love-compute/branding/i-love-compute.256.png) 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](https://github.com/kpet/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!](https://gitlab.com/illwieckz/i-love-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](https://gitlab.com/illwieckz/i-love-compute#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](https://gitlab.com/illwieckz/i-love-compute/-/issues) 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à](https://gitlab.com/illwieckz/i-love-compute#hardware-donation). 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](https://unvanquished.net), avec [ce genre de tableau](https://wiki.unvanquished.net/wiki/GPU_compatibility_matrix) (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](https://gitlab.com/illwieckz/i-love-compute#funding) 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](https://rebuild.sh) 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](https://github.com/RadeonOpenCompute/ROCm/blob/c3f91afb2688deb638c360497e35b249f8026667/README.md#hardware-and-software-support) officiellement considérées et il est dit que [les applications graphiques ne sont pas prises en charge](https://github.com/RadeonOpenCompute/ROCm/blob/95493f625cadb3457cedb454e4ebd0df7b991443/README.md?plain=1#L194). Il y a quelques tentatives de faire tourner OpenCL sur Vulkan, comme [clvk](https://github.com/kpet/clvk) qui repose sur [clspv](https://github.com/google/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 ?