Difficile de le nier, NVIDIA fait fort côté écosystème. Si cela est clairement visible sur le segment gaming avec diverses technologies tels le RTX, le DLSS ou encore les applications de démonstration des performances du machine learning comme RTX Voice ou NVIDIA Canvas, le caméléon sait où graisser des pattes pour développer du logiciel qui en met plein la vue. Dans la sphère professionnelle, le diapason est à peu près le même, notamment grâce à CUDA : un framework (ou cadriciel si vous être de l’Académie française !) servant à déporter du calcul scientifique sur sa carte graphique. À sa naissance, CUDA a popularisé ce que l’on nomme actuellement GP-GPU (General Purpose – GPU: du GPU pour autre chose que des images en 3D) ! Depuis, la concurrence d’Intel et AMD a eu le temps de s’adapter avec l’émergence d’OpenCL (et, en son temps, la concurrence d'AMD FireStream) puis plus récemment de HIP, des alternatives plus ouvertes, mais nécessitant un flot d’exécution bien séparé.
Ainsi, un des freins à l’utilisation de matériel concurrent de NVIDIA réside dans la nécessité de porter son code depuis du CUDA propriétaire vers de l’OpenCL cross-plateforme (et connu pour être étrangement moins performant sur les cartes vertes), ou tout autre API propre au nouveau matériel. Vous comprenez donc que des projets de conversion automatique aient vu le jour, en particulier ZLUDA qui, en 2020, proposait de faire tourner du CUDA sur iGPU Intel. Au cœur du projet, un remplacement au back-end du caméléon par l’API Level Zero des bleus, qui propose peu ou prou les mêmes primitives. Il « suffit » alors de traduire les appels CUDA en appels Level Zero et boum ! L’écosystème devient compatible sans avoir à modifier les applications ciblées. Cela vous semble familier ? Hé oui, le principe est assez proche dans son mode d’opération à ce que propose Proton pour faire mouliner des jeux dépendants de Windows sur Linux.
Tout cela est bien beau, mais que vient faire AMD dans cette équation ? En fait, le développeur de ZLUDA, Andrzej Janik, a été chargé par AMD en 2022 d’adapter ce code pour supporter les cartes Radeon, de manière à adapter le projet pour le rendre compatible avec le matériel de la firme. C’est ainsi que, avant-hier, une mise à jour de ZLUDA (la dernière depuis février 2021 !) portait ces notes :
Nobody expects the Red Team
Too many changes to list, but broadly:
* Remove Intel GPU support from the compiler
* Add AMD GPU support to the compiler
* Remove Intel GPU host code
* Add AMD GPU host code
* More device instructions. From 40 to 68
* More host functions. From 48 to 184
* Add proof of concept implementation of OptiX framework
* Add minimal support of cuDNN, cuBLAS, cuSPARSE, cuFFT, NCCL, NVML
* Improve ZLUDA launcher for Windows
Ça, c’est de la documentation !
Que les fans rouges se rassoient : si le code est passé open source, c’est parce que son développement a été une nouvelle fois stoppé. Pourtant capable de tourner sans bidouilles sur des vraies applications telles Blender ou Geekbench (mais limité de manière stable à RDNA2) en utilisant sous le capot l’écosystème ROCm d’AMD dans sa version 5 (dommage pour la 6, qui vient de sortir !), le projet a été jugé d’une utilité inférieure à son coût par la firme, qui stoppe son financement. Pour autant, atteindre un tel niveau d’utilisabilité pour un logiciel développé par une seule personne est remarquable… tant pis.
Au niveau des performances, ZLUDA va parfois dépasser la version OpenCL/HIP « officielle », parfois lamentablement s’écraser selon les cas. Une performance de taille, car le code CUDA n’a aucune raison d’être optimisé pour les architectures rouges : autant dire qu’il y a matière à optimiser davantage en touchant au code source.
Dans ces conditions, pourquoi arrêter le projet ? La question est d’autant plus légitime que le coût du développeur doit rester relativement limité, surtout mis en perspective avec la taille d’AMD. La réponse n’a pas été donnée officiellement, mais nous pouvons nous aventurer assez facilement à quelques éléments. Avec le développement et l’intégration de plus en plus poussée de ROCm, une position tarifaire agressive pour des performances compétitives, les intérêts des rouges évoluent. Dans ce contexte, encourager un support du logiciel du concurrent relève plus de la balle dans le pied que du projet visant à rameuter des utilisateurs — l’objectif initial. Rajoutons à cela un risque de problèmes juridiques, CUDA étant licencié à NVIDA… Dans ce cas, AMD continue sur sa ligne habituelle de laisser le projet vivre en open source, l’occasion de potentiellement continuer son développement sans avoir à y injecter des fonds, et dans tous les cas de valoriser le travail effectué par toujours plus de com'. À voir si ZLUDA prend son envol de lui-même, mais rien n’est moins sûr !
Par ici pour le test complet des performances chez Phoronix
Par là pour le code et sa documentation !
Les premiers à avoir utilisé de mémoire les gpu pour autre chose que de la 3D ou de la vidéo est ATi avec sream. On pouvait faire de gpgpu avec des cartes dx9
Quel dommage d'avoir racheté les premiers à faire un truc aussi intéressant, et de se retrouver maintenant relégué dernière la concurrence. Ça doit certainement faire partie des trucs dans lesquels AMD avait sabré pour limiter les pertes ou investissements peu rentables immédiatement, alors en difficulté financière pendant une (trop) longue période. Mais bon, on aura vu des retournement plus singulier ou inattendus, et AMD peu encore faire parler la poudre pour repasser devant, même si le marché des pro est probablement plus difficile à convaincre et faire basculer que les particuliers.
Après, je doute que le machin d'ATi ait vraiment été utilisé de manière commerciale ou soit officiellement sorti en version stable.
C'était moins haut niveau que du CUDA en matière d'abstraction mais c'est tout à fait vrai, j'ai édité en consequence :-)
A noter que OpenCL est pratiquement mort
Que ce soit vulkan ou opencl, je ne dirai pas que c'est mort mais que c'est assez mature, donc pas besoin pour le moment de tout changer sur un truc qui marche. La dernière stable release a un an, elle a été mise à jour il y a deux mois, je n'ai pas eu de soucis avec. Quand à améliorer, effectivement, y'a de la marge, mais si les trucs potentiellement améliorables sont sous brevet, ceci explique cela.
Enfin, il faut noter que le chair du groupe de travail Opencl est Neil Trevett de NVIDIA... ceci doit aussi contribuer à expliquer cela. On voit l'avantage politique à nommer une pesonne de la boite porteuse du principal concurrent à opencl, mais en terme de travail, c'est un mauvais calcul. En comparaison, Mike Blumenkrantz (steam) et Tom Olson (arm) sont beaucoup plus actifs à animer leurs groupes de travail respectifs (opengl et vulkan). En opencl, tous les sous-responsables sont d'intel, c'est piteux qu'il n'y ait aucune personne d'AMD dans les animateurs de groupe opencl. Est-ce un choix délibéré d'AMD de laisser tomber opencl ? A mon sens, il devrait aussi y avoir un groupe de travail chargé des wrappers dans les différents langages de façon à stimuler l'utilisation d'opencl plus largement. Cuda est actif sur ce plan.
Mon interrogation à lire cet article c'est pourquoi ne pas importer dans opencl (donc en opensource) les améliorations plutôt que de faire un wrapper (bien comme première approche rapide mais ...).
De quelles améliorations tu parles ? Le OpenCL est globalement un équivalent à CUDA en un peu plus verbeux, mais il ne me semble pas que le choix de CUDA par rapport à OpenCL (et les migrations) soit motivé par des raisons autres que historiques, ou par une influence de NVIDIA dans la décision (notamment en fournissant des performances optimisées sur leur propre langage)...
Perso, je n'utilise que opencl via pyopencl quand j'ai besoin (car opensource et surtout je change de machine donc de hardware), et j'en suis très heureux (et je ne vais pas me taper un nouvel apprentissage) donc je ne sais donc pas du tout côté Cuda. Je ne répercute que les dires de mes collègues qui utilisent également cuda m'assurant que le calcul matriciel (de mémoire, inversion et diagonalisation de matrice) est plus performant sur cuda (et effectivement, que le code est plus maintenable sur cuda), et mes souvenirs de rares tests comme phoronix qui ont abordé cette comparaison.