Le projet open source ZLUDA permet d’exécuter des applications CUDA sur des GPU AMD

ZLUDA permet d’exécuter des applications CUDA sur des GPU AMD

• ZLUDA 3, un projet open source développé par Andrzej Janik, permet d’exécuter sur du matériel d’autres fabricants des applications GPU conçues pour les GPU NVIDIA.
• Cette technologie est conçue pour permettre l’exécution d’applications existantes sur un nouveau matériel sans travail supplémentaire de la part des développeurs.
• Les versions précédentes de ZLUDA permettaient d’exécuter des applications CUDA sur des GPU Intel, mais la version 3 vise désormais les GPU AMD.

ZLUDA n’était-il pas destiné aux GPU Intel ?

• ZLUDA a été lancé pour la première fois en 2020 comme alternative à CUDA pour les GPU Intel.
• Après la sortie de la version 2 en 2021, Janik a annoncé qu’il ne pouvait pas poursuivre le développement du projet, mais Intel a ensuite commencé à évaluer ZLUDA comme technologie officielle.
• Intel a finalement décidé qu’il n’existait pas de justification commerciale à l’exécution d’applications CUDA sur des GPU Intel, et Janik a quitté l’entreprise pour approcher AMD.
• AMD a évalué ZLUDA pendant deux ans, mais a décidé de ne pas poursuivre le projet, et Janik a publié en open source le code mis à jour.

Pourquoi est-ce important pour les artistes CG ?

• La version 3 de ZLUDA permet d’exécuter sur des GPU AMD des applications GPU développées avec l’API CUDA de NVIDIA.
• Dans des secteurs comme les VFX, le motion design et la visualisation, de nombreuses applications CG majeures, en particulier les moteurs de rendu, reposent sur CUDA et sont réservées à NVIDIA.
• AMD dispose de sa propre technologie, HIP, mais son adoption exige du travail de la part des développeurs logiciels.
• ZLUDA est en réalité construit sur HIP et conçu pour permettre l’exécution d’applications CUDA sur des GPU AMD sans modification.

À quelle vitesse les applications CUDA s’exécutent-elles avec ZLUDA ?

• Janik explique que les applications CUDA tournent sur les GPU AMD avec des « performances presque natives ».
• Cependant, selon le dépôt GitHub de ZLUDA, 3DF Zephyr et RealityCapture sont « beaucoup plus lents » avec ZLUDA.
• De nombreux développeurs de moteurs de rendu GPU utilisent aussi OptiX, une seconde API de NVIDIA qui contribue aux performances, et ZLUDA n’offre qu’un support « minimal » d’OptiX.

D’autres applications CG peuvent-elles fonctionner sur des GPU AMD via ZLUDA ?

• Sans tests utilisateurs, il est difficile de dire à quel point d’autres applications CG basées sur CUDA fonctionneront bien avec ZLUDA.
• De nombreux problèmes connus subsistent, et Janik n’a obtenu qu’un succès limité avec d’autres moteurs de rendu GPU.

Est-il possible que davantage d’applications CG basées sur CUDA fonctionnent avec ZLUDA à l’avenir ?

• Janik affirme que, sans soutien d’Intel ou d’AMD, ZLUDA est « en pratique abandonné ».
• Il se dit ouvert à des propositions pouvant faire avancer le projet, mais sinon il ne prendra probablement en charge que les technologies NVIDIA qui l’intéressent personnellement.
• Le code source est disponible publiquement et, même dans son état actuel, ZLUDA peut servir aux développeurs comme élément d’un « portage plus progressif » de CUDA vers HIP.

Licence et configuration requise

• Des versions compilées de ZLUDA 3 sont disponibles pour Windows et Linux. Le code source est proposé sous licence Apache 2.0 ou MIT.

L’avis de GN⁺

• ZLUDA a le potentiel de stimuler la concurrence sur le marché des GPU en ouvrant l’écosystème propriétaire CUDA de NVIDIA aux utilisateurs d’AMD.
• Le projet peut notamment profiter aux utilisateurs de logiciels de rendu ou d’applications de calcul scientifique dépendants de CUDA, en leur offrant davantage d’options matérielles.
• Cependant, comme ZLUDA en est encore à un stade précoce et n’offre pas encore des performances ni une compatibilité complètes, son adoption dans des environnements de production réels doit être envisagée avec prudence.
• Réduire l’écart technologique entre AMD et NVIDIA pourrait offrir aux consommateurs de meilleurs prix et plus de choix, favorisant ainsi une concurrence saine sur le marché.
• L’intérêt et les contributions continus de la communauté open source seront essentiels au succès du projet, tout en offrant une bonne opportunité de contribution aux experts du domaine.

[GN⁺]

Commentaires sur Hacker News

• Discussion précédente il y a 22 jours : AMD développe une implémentation de CUDA basée sur ROCm et la publie en open source [0], avec 400 commentaires.

  • Commentaire de premier niveau notable dans ce fil :

    AMD a décidé, après 2 ans de développement, qu’il n’y avait pas de justification économique à faire tourner des applications CUDA sur des GPU AMD. L’une des clauses du contrat était que si AMD jugeait que le développement n’était plus pertinent, cela pouvait être rendu public. Nous en sommes donc là aujourd’hui. - Voir la FAQ de ZLUDA

  • Lien connexe : discussion Hacker News

• Il est totalement absurde qu’AMD ait cessé de financer ce projet. Dès qu’il a été publié en open source, il a commencé à apporter de la valeur aux utilisateurs d’AMD, ce qui devrait pourtant sembler être une priorité absolue pour AMD, alors que l’entreprise a perdu des années avec deux (ou trois ?) API alternatives qui n’ont reçu quasiment aucun support jusqu’à présent.

• Élément lié dans la discussion : Nvidia interdit l’utilisation de couches de traduction pour son logiciel CUDA afin de l’exécuter sur d’autres puces [1]

  • Lien connexe : discussion Hacker News

• Intel finira aussi par décider qu’il n’y a pas de « justification économique pour faire tourner des applications CUDA sur des GPU Intel ». Cela ne fait que confirmer ce que sait déjà toute personne ayant eu affaire au GPGPU chez AMD.

• Le fait que le software d’AMD soit extrêmement mauvais est bien connu, et c’est le seul élément qui empêche AMD de devenir une entreprise à 2 000 milliards de dollars. Il y avait des bugs dans le compilateur OpenCL d’AMD, et il était facile de faire planter le compilateur via un segfault (j’ai fini par abandonner sans le signaler). Le fait qu’AMD n’ait pas développé de concurrent à CUDA relève d’une vision extrêmement court-termiste. Je ne comprends pas pourquoi le conseil d’administration d’AMD n’a pas été remplacé. Vous pouvez fabriquer le meilleur hardware du monde ; si le software pour l’utiliser est mauvais, personne ne l’achètera ni ne l’utilisera. En tant que client, j’ai l’impression que le conseil d’administration d’AMD se moque des milliers de milliards de dollars de valeur laissés sur la table, et je n’ai donc pas d’autre choix que d’acheter des cartes Nvidia surévaluées. Les détenteurs d’actions AMD devraient poser des questions, et ce conseil d’administration devrait finir dans la bouche d’égout la plus proche.

• Je me demande s’il existe un langage de programmation capable de compiler vers différents langages de noyau, comme Metal, CUDA, et ce qu’AMD possède. Si ce n’est pas le cas, pourquoi ? De la même manière qu’il existe des compilateurs C pour diverses architectures CPU, ne devrait-il pas y avoir des compilateurs pour architectures GPU ? Peut-être que personne ne l’a encore fait.

• Je me demande si quelqu’un a essayé d’exécuter cela avec un outil OSS de photogrammétrie comme Meshroom. L’article mentionne quelques éléments propriétaires, mais il n’en faut pas tant que ça.

• Le problème des GPU AMD, ce ne sont pas les kernels individuels, mais les bibliothèques. Le fait que les notes de version mentionnent « ajout d’un support minimal pour cuDNN, cuBLAS, cuSPARSE, cuFFT, NCCL et NVML » semble indiquer que le projet avançait dans cette direction. Personne ne sait si le projet pourra garder son élan après l’arrêt du financement par AMD.

• C’est presque exactement le même problème que l’utilisation du bytecode JVM dans l’affaire Oracle contre Google.

• Le combat continu (et coûteux) de geohot avec les GPU AMD est aussi lié à ce sujet : lien Twitter