ZLUDA, un projet open source pour exécuter des apps CUDA sur des GPU AMD

 (cgchannel.com)
3 points par GN⁺ 2024-03-06 | 1 commentaires | Partager sur WhatsApp
  • ZLUDA 3 est une technologie open source visant à exécuter sans modification, sur des GPU AMD, des applications conçues pour les GPU NVIDIA et dépendantes de CUDA
  • Initialement lancé comme implémentation de remplacement de CUDA pour les GPU Intel, le projet a vu les évaluations d’Intel puis d’AMD s’arrêter ; cette fois, c’est le code ciblant les GPU AMD qui est publié
  • Dans Blender, certains cas affichent des performances proches du backend HIP natif, mais 3DF Zephyr et RealityCapture sont indiqués comme « much slower » avec ZLUDA, ce qui montre de fortes variations selon les apps
  • La possibilité d’exécuter des apps CG réservées à NVIDIA, comme RealityCapture et Arnold, a été confirmée, mais la prise en charge d’OptiX reste minimale sous Linux, ce qui limite les workflows de rendu
  • Sans soutien d’Intel ni d’AMD, le projet est proche d’un état « realistically now abandoned », et la licence du SDK NVIDIA restreint aussi le développement de couches de traduction destinées aux plateformes non-NVIDIA

Le problème de dépendance à CUDA que ZLUDA 3 veut résoudre

  • ZLUDA 3 est un projet open source qui permet d’exécuter sur du matériel d’autres fabricants des applications GPU créées pour les GPU NVIDIA
  • Il est conçu pour exécuter les applications existantes sans modification sur un nouveau matériel, sans exiger de travail de portage supplémentaire de la part des développeurs d’apps
  • ZLUDA a été publié pour la première fois en 2020 comme implémentation drop-in de remplacement de CUDA pour les GPU Intel, puis la poursuite du développement est devenue difficile après la version 2 en 2021
  • En 2021, alors qu’Andrzej Janik travaillait chez Intel, Intel a évalué ZLUDA comme candidat technologique officiel, mais a conclu qu’il n’existait « pas de business case pour exécuter des applications CUDA sur des GPU Intel »
  • Après avoir quitté Intel en 2022, Janik a approché AMD, qui a également évalué ZLUDA pendant deux ans avant de décider de ne pas aller plus loin
  • Le code mis à jour a ensuite été publié en open source, et le contexte est détaillé dans l’article de Phoronix

Périmètre de fonctionnement vérifié dans les apps CG

  • ZLUDA 3 vise à exécuter sur des GPU AMD des apps GPU développées avec l’API CUDA de NVIDIA
  • Dans les domaines des VFX, du motion graphics et de la visualisation, certaines apps CG et moteurs de rendu clés reposent sur CUDA et restent donc, de fait, réservés à NVIDIA
  • HIP d’AMD est une technologie permettant de porter des apps CUDA vers le matériel AMD, mais elle nécessite une intervention des développeurs logiciel
    • HIP est utilisé pour les versions compatibles AMD de Redshift et de Cycles dans Blender
    • ZLUDA 3 est lui aussi construit sur HIP, mais son objectif est l’exécution sans modification des apps CUDA existantes
  • Les logiciels réservés à NVIDIA que Janik a testés avec ZLUDA incluent 3DF Zephyr, RealityCapture et Arnold d’Autodesk
  • La prise en charge d’Arnold relève du proof of concept, et les scènes rendues avec succès via l’implémentation OptiX de ZLUDA restent limitées

Les limites pratiques de performance et de compatibilité

  • Janik estime que les apps CUDA s’exécutent sur GPU AMD avec des performances « near-native performance »
  • Selon les benchmarks de Phoronix et un fil du forum Blender Artists, il existe des cas où les performances de ZLUDA dans Blender sont similaires à celles du backend HIP natif
  • En revanche, le dépôt GitHub de ZLUDA indique que 3DF Zephyr et RealityCapture sont much slower avec ZLUDA
  • Beaucoup de moteurs de rendu GPU utilisent aussi OptiX de NVIDIA en plus de CUDA pour l’accélération du ray tracing
    • La prise en charge d’OptiX par ZLUDA est au niveau « minimum »
    • La prise en charge d’OptiX existe uniquement sous Linux, pas sous Windows
    • L’état de l’implémentation est « buggy, unoptimized and incomplete »
    • ZLUDA-OptiX n’est pas inclus dans les versions redistribuées et doit être compilé soi-même
  • La possibilité d’exécuter d’autres apps CG basées sur CUDA est difficile à évaluer sans tests utilisateurs

Pérennité du projet et contraintes de licence

  • Janik considère que, sans soutien d’Intel ou d’AMD, ZLUDA est dans un état « realistically now abandoned »
    • Il reste ouvert aux propositions qui feraient avancer le projet
    • À défaut, il est surtout probable qu’il ajoute seulement la prise en charge de technologies NVIDIA qui l’intéressent personnellement, comme DLSS
    • Le code actuel peut aussi être utile aux développeurs logiciel qui effectuent un portage progressif de CUDA vers HIP
  • Selon une mise à jour du 14 mars 2024, Tom’s Hardware souligne que les conditions de licence du SDK de NVIDIA interdisent d’utiliser les livrables du SDK, y compris CUDA Toolkit, pour développer des technologies de traduction destinées à des plateformes non-NVIDIA
  • Les versions compilées de ZLUDA 3 sont disponibles pour Windows et Linux, et le code source est proposé sous Apache 2.0 ou MIT license
  • ZLUDA 3 peut être téléchargé depuis le dépôt GitHub du projet

À lire aussi

1 commentaires

 
GN⁺ 2024-03-06
Commentaires sur Hacker News

  • Il y a eu une discussion liée il y a 22 jours aussi : un billet expliquant qu’AMD avait financé une implémentation drop-in de CUDA basée sur ROCm, puis l’avait publiée en open source [0], a reçu 400 commentaires
    Le commentaire de premier niveau le plus notable dans ce fil expliquait que la publication elle-même était la conséquence de l’arrêt du financement par AMD : « Après 2 ans de développement et d’évaluation, AMD a conclu qu’il n’y avait pas de viabilité commerciale à exécuter des applications CUDA sur des GPU AMD. L’une des clauses de mon contrat avec AMD était que je pouvais publier le projet si AMD jugeait qu’il ne convenait pas à un développement supplémentaire. Nous y voilà donc aujourd’hui. » Source : https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq
    [0] https://news.ycombinator.com/item?id=39344815

  • Le fait qu’AMD ait coupé le financement de ce projet est vraiment absurde. Dès son passage en open source, il a commencé à créer de la valeur pour les utilisateurs d’AMD
    Ce genre de chose devrait être la priorité absolue d’AMD, et pourtant l’entreprise s’est perdue pendant des années à s’accrocher à deux API alternatives à peine soutenues, voire trois maintenant

    • Dès que cela deviendra une option crédible, Nvidia enverra immédiatement une mise en demeure et intentera un procès. Comme solution sérieuse, c’est une impasse, donc dans ce contexte c’est compréhensible
    • C’est peut-être parce qu’ils veulent pousser les gens à utiliser HIP
      « HIP est très léger, avec peu ou pas d’impact sur les performances par rapport à un développement direct en mode CUDA »
      « L’outil HIPIFY convertit automatiquement le code source CUDA en HIP »
      1. https://github.com/ROCm/HIP
    • D’un point de vue stratégique, difficile d’y voir le meilleur choix pour AMD. À moins que ce ne soit au niveau produit et juridiquement validé, ce n’est qu’un outil permettant aux développeurs de créer des applications sur AMD puis de les déployer sur Nvidia
      Du côté des cartes graphiques grand public, cela peut représenter un gain à court terme, mais à long terme c’est presque un but contre son camp qui ne fait que consolider la position de Nvidia dans les datacenters
    • Il est très probable qu’AMD ait été informé à l’avance de l’annonce de NVIDIA et ait relâché ce prestataire. Selon les termes du contrat, le projet serait alors devenu open source
    • On part ici de l’hypothèse qu’AMD a choisi d’abandonner. Et s’ils étaient simplement en train de construire quelque chose de meilleur ?

  • Cette discussion semble aussi liée au billet disant que « Nvidia a interdit l’usage de couches de traduction pour exécuter des logiciels CUDA sur d’autres puces » [1]

    [1] https://news.ycombinator.com/item?id=39592689

    • Si l’on n’utilise pas de matériel Nvidia, pas de pilotes Nvidia, et qu’on n’a jamais accepté l’EULA de Nvidia, je ne vois pas pourquoi on devrait s’en soucier
      L’émulation bénéficie d’une protection juridique explicite et jurisprudentielle. La reproduction d’API à des fins de compatibilité est allée jusqu’à la Cour suprême des États-Unis, qui a jugé que cela ne relevait pas du droit d’auteur. Du moins, c’est vrai dans un cadre assez large
      Je ne suis pas avocat, mais j’ai du mal à voir sur quelle base juridique Nvidia compte s’appuyer. Pour un individu ou une entreprise n’ayant aucun matériel Nvidia, cela ressemble à une question sans portée. Pour une entreprise qui possède déjà du matériel Nvidia, on peut peut-être soutenir certains arguments, mais cela ne tombe-t-il pas alors en plein dans le champ des pratiques anticoncurrentielles ?
    • Je ne vois pas en quoi c’est différent de Wine/Proton. Il doit probablement y avoir des clauses semblables dans l’EULA de Microsoft ; si elles avaient été applicables, Microsoft n’aurait-il pas envoyé la même mise en demeure aux développeurs de Wine ?
    • Il faut rappeler que, contrairement à ce qu’affirme l’article, cette clause figurait déjà dans l’EULA CUDA depuis janvier 2022 et, contrairement à la mise à jour de l’article, qu’elle était aussi incluse dans le téléchargement
    • Est-ce que cela a vraiment une importance ? On n’a pas besoin de la permission de quelqu’un pour implémenter un système ayant une interface compatible avec un autre système
      Cela viole l’EULA, mais tant qu’on ne télécharge pas le logiciel CUDA, on n’a pas besoin d’accepter l’EULA, et les auteurs de ZLUDA ont probablement pu éviter cela
    • NVIDIA n’a pas le droit de faire ça. Le SDK NVIDIA n’entre pas en jeu ici

  • Dire qu’« Intel aussi a fini par conclure qu’il n’y avait pas de viabilité commerciale à exécuter des applications CUDA sur des GPU Intel », c’est tout de même déprimant

    • En résumé, toute entreprise qui atteint une certaine taille et un certain âge finit par rêver d’être un monopoliste plutôt que de défier le monopole en place
    • La division graphique d’Intel était tellement mauvaise que, à cause de la mauvaise image laissée dans l’esprit des gens, ils ont dû abandonner le nom Intel HD

  • Cela confirme ce que sait toute personne ayant déjà touché au GPGPU d’AMD. La seule chose qui empêche AMD de devenir une entreprise à 2 billions de dollars, c’est vraiment un logiciel épouvantable
    Je me souviens avoir trouvé un bug dans le compilateur OpenCL d’AMD [1], et il était aussi très facile de faire planter le compilateur OpenCL avec une erreur de segmentation. Ça n’a jamais été corrigé, donc j’ai fini par abandonner le signalement
    Le fait qu’AMD n’ait pas développé de concurrent à CUDA est l’une des décisions les plus court-termistes que j’aie jamais vues. Je ne comprends pas pourquoi le conseil d’administration n’a pas été remplacé par des gens capables de comprendre que, même si on fabrique le meilleur matériel, si le logiciel qui va avec est médiocre — pour rester poli — personne ne l’achètera ni ne l’utilisera
    Nous, les clients, sommes donc forcés d’acheter des cartes Nvidia coûteuses, parce qu’AMD est manifestement trop riche pour se soucier du trillion de dollars de valeur que son conseil d’administration a laissé sur la table. Quiconque détient des actions AMD devrait poser des questions. Ce conseil devrait partir par la sortie la plus proche
    [1] https://github.com/msoos/amdmiscompile -- ça a fini par être corrigé

    • Quelqu’un peut m’expliquer ce qu’est le GPGPU comme si j’étais JavaScript ?
      Dans ma compréhension naïve, une carte graphique est une sorte d’ordinateur étrange sur lequel on peut charger des instructions et des données puis le laisser faire ses calculs
      Je ne vois pas pourquoi CUDA est si important. Pourquoi AMD ne permettrait-il pas d’accéder directement à ses GPU comme à un tableau de 4096 cartes Arduino ?
    • Oui. À l’inverse, AMD est en général plus favorable à l’open source que Nvidia. Nvidia a longtemps été activement hostile, il suffit de voir la vidéo du “F* you!” de Linus
      Les entreprises qui développent du matériel sont généralement mauvaises en logiciel. Il y a des exceptions, mais elles sont rares, et ces entreprises ont effectivement été récompensées en Bourse. Je ne connais pas la culture de la division logicielle d’AMD, mais en général, corriger ce genre de problème demande des changements assez profonds
      Remplacer seulement le conseil d’administration ne suffira probablement pas. À moins que les directives de la direction générale soient l’unique facteur qui tire l’entreprise vers le bas, il faudrait changer bien plus de niveaux de management, et remplacer aussi une bonne partie des managers intermédiaires. Si le recrutement logiciel a été mauvais, il faut parfois aller jusqu’aux contributeurs individuels
    • Je ne comprends pas pourquoi AMD ne collabore pas avec Intel pour pousser SYCL comme standard du GPGPU et de la programmation hétérogène
      Intel est bon en logiciel, SYCL est un standard ouvert, les deux entreprises pourraient donc bénéficier du même code, et les clients pourraient faire tourner du code SYCL sur un Threadripper s’ils le souhaitent. Certains Threadripper actuels sont même aussi rapides que certains GPU
      AMD essaie de construire son propre écosystème propriétaire verrouillé ? Je ne comprends pas pourquoi ils ne s’engagent pas sur un standard ouvert multiplateforme
    • Moi, j’aimais plutôt bien AMD Software lui-même. Il était facile de limiter le framerate à 60 pour empêcher le GPU de tourner à fond quand le jeu ou le logiciel ne le faisait pas nativement, et on pouvait aussi configurer un raccourci d’instant replay qui enregistre en continu les dernières minutes, comme Shadowplay
      Quand mon onduleur n’était pas très bon, je pouvais aussi limiter la puissance du GPU, et je pouvais utiliser l’overclocking automatique pour garder ma RX 580 environ un an de plus
      En revanche, les logiciels/pilotes depuis environ 2020 faisaient planter les titres VR en moins d’une heure. Il n’y a pas non plus de paquet logiciel pour Linux, et CoreCtrl n’est pas aussi bien. Il arrive aussi que l’instant replay ne fonctionne tout simplement pas. Je n’ai jamais réussi à faire marcher correctement ROCm avec des LLM locaux, ni sous Windows ni sous Linux, et DKMS adorait lancer tout un tas de compilations inutiles à chaque apt upgrade
      J’hésite entre prendre une Intel Arc par curiosité pour mon prochain GPU, ou simplement revenir chez Nvidia. Les candidats seraient l’A580, la RX 6600 ou la RTX 3050, à moins que je ne tienne jusqu’à ce que le prix des autres composants baisse

  • Existe-t-il un langage de programmation qui se compile vers plusieurs langages de noyau comme Metal, CUDA, ou quelque chose du côté d’AMD ? Sinon, pourquoi ?
    Les compilateurs C compilent vers de nombreuses architectures CPU. Il devrait bien y avoir des compilateurs vers des architectures GPU, non ? Peut-être que personne ne l’a encore fait

    • On peut compter OpenCL aussi ?
      https://www.khronos.org/api/opencl
    • OpenMP 5 a explicitement ajouté le support GPU. Après une recherche rapide, il semble qu’au moins certains compilateurs le prennent désormais en charge, au moins partiellement

  • Quelqu’un a essayé ça pour faire tourner des outils open source de photogrammétrie comme Meshroom ? L’article mentionne quelques outils propriétaires, mais mes besoins sont assez modestes

  • Ça ressemble presque exactement à l’affaire Oracle contre Google autour de l’utilisation du bytecode JVM

    • Je ne trouve pas. Le sujet n’est pas la transformation du bytecode, mais le fait d’attacher une propriété intellectuelle de bibliothèque de plus haut niveau au matériel
      C’est un peu comme si Google disait : “nos applications Android ne peuvent s’exécuter que sur des téléphones approuvés par Google”. Si j’ai bien compris, Google fait effectivement quelque chose de ce genre pour le framework Play ou pour Maps

  • J’ai entendu récemment une rumeur intéressante : la personne chez NVIDIA qui s’occupait de CUDA se serait battue pendant des années pour obtenir des ressources et convaincre l’entreprise de prendre ce projet au sérieux
    Sans CUDA, NVIDIA ne serait absolument jamais devenue l’entreprise à presque un trillion de dollars qu’elle est aujourd’hui

  • Le fait que geohot ait lui aussi continué à se battre avec des GPU AMD coûteux est lié à ça : https://twitter.com/tinygrad/status/1764734675002810622