CUDA pour AMD sous Windows fonctionne, mais uniquement via une voie de compatibilité étroite
Les utilisateurs d’AMD disposent désormais d’une configuration reproductible permettant d’exécuter CUDA pour AMD sous Windows, bien que CUDA reste une plateforme NVIDIA. Le projet communautaire traduit certains appels CUDA via ZLUDA, puis les exécute par l’intermédiaire des bibliothèques HIP d’AMD. Son créateur indique avoir mené à bien une charge de travail d’entraînement IA sur une Radeon RX 9060 XT.
Cette réalisation est importante, car elle franchit une frontière difficile. Les développeurs peuvent partir d’une application Windows conçue pour la pile logicielle de NVIDIA et l’exécuter sur une configuration AMD prise en charge. Ils n’ont pas besoin de réécrire d’abord cette application pour HIP.
Toutefois, ce résultat ne rend pas CUDA indépendant du matériel. La configuration dépend d’une couche de compatibilité, de versions logicielles figées et de remplacements incomplets de bibliothèques. Un seul modèle de GPU possède actuellement un statut validé dans le projet.
La véritable concurrence ne se joue donc pas simplement entre le matériel AMD et NVIDIA. Elle oppose la compatibilité avec les applications CUDA existantes à la fiabilité de la prise en charge native par le fournisseur. La nouvelle configuration fait progresser le premier objectif sans offrir le second.
Le projet transforme un binaire CUDA en charge de travail AMD
Le changement majeur est l’existence d’un parcours documenté et reproductible reliant une application Windows orientée CUDA à un GPU AMD.
Le projet de compatibilité open source regroupe l’installation, la préparation de l’exécution, les diagnostics et les scripts de validation. Il s’appuie sur ZLUDA et les logiciels HIP d’AMD pour Windows plutôt que d’implémenter un autre environnement d’exécution GPU à partir de zéro.
ZLUDA est une couche de traduction qui présente des interfaces compatibles avec CUDA à une application. Elle redirige les opérations prises en charge vers les fonctions correspondantes disponibles dans la pile GPU hôte.
HIP, l’interface de calcul hétérogène pour la portabilité, est l’environnement d’exécution C++ et le langage de noyaux d’AMD pour les logiciels GPU portables. Dans cette configuration, HIP fournit la couche inférieure qui communique en définitive avec le GPU Radeon.
Le parcours commence avec un programme Windows qui attend des composants NVIDIA CUDA. ZLUDA reçoit ces appels et achemine les opérations de bibliothèque prises en charge vers leurs équivalents AMD.
Par exemple, les opérations cuBLAS peuvent atteindre rocBLAS, tandis que les appels cuSPARSE peuvent atteindre rocSPARSE. Ces bibliothèques traitent les charges de travail courantes d’algèbre linéaire et de matrices creuses.
Le dépôt comprend un programme d’installation PowerShell qui vérifie le GPU détecté, le pilote, le SDK HIP et les bibliothèques mathématiques requises. Il télécharge ensuite une version figée de ZLUDA et vérifie les fichiers téléchargés à l’aide de hachages SHA-256.
Le programme d’installation peut aussi récupérer LibTorch 2.3.0 compilé pour CUDA 11.8. LibTorch est la distribution C++ de PyTorch, utilisée lorsque les applications intègrent des fonctions PyTorch sans environnement d’exécution Python.
Ce téléchargement représente environ 2,66 Go, selon le dépôt. Les utilisateurs qui n’ont pas besoin de LibTorch peuvent l’ignorer.
Après l’installation, les scripts créent des rapports d’exécution et de GPU propres à la machine. Un autre outil de diagnostic exécute l’utilitaire cuda_check de ZLUDA sur la pile AMD installée.
Le lancement d’une application nécessite le script enveloppe du projet. Il place les bibliothèques de compatibilité nécessaires à côté de l’exécutable cible et configure les chemins d’exécution HIP pour ce processus.
Ce modèle de préparation locale limite les changements à l’échelle du système. Il révèle aussi une faiblesse centrale : chaque application dépend toujours des fonctions et bibliothèques CUDA exactes que ZLUDA peut traduire.
Le projet indique des vérifications réussies de l’interface de pilote CUDA, de cuBLAS, cuBLASLt, cuSPARSE et cuFFT. Ces résultats s’appliquent à sa machine validée et à sa combinaison logicielle.
Ils n’établissent pas une compatibilité générale entre les applications Windows. Un programme peut réussir les vérifications de base de l’environnement d’exécution, puis atteindre ultérieurement une fonction non prise en charge lors d’une autre charge de travail.
Le dépôt précise que seule la Radeon RX 9060 XT, identifiée par la cible gfx1200 d’AMD, possède le statut de référence validée. Les autres architectures Radeon détectées restent des candidates non vérifiées.
Cette formulation est importante. La détection signifie qu’un script reconnaît l’appareil et son architecture. Elle ne signifie pas que l’application, la couche de traduction et les bibliothèques fonctionneront ensemble.
Pourquoi CUDA pour AMD sous Windows importe aujourd’hui
Le projet s’attaque au coût de migration des applications CUDA, et non à la propriété de CUDA ou à l’avantage matériel de NVIDIA.
CUDA est la plateforme et le modèle de programmation parallèle de NVIDIA. Son modèle de programmation couvre l’exécution des noyaux, la gestion de la mémoire, la synchronisation et les bibliothèques optimisées pour les GPU NVIDIA.
De nombreuses applications dépendent de bien plus que du code source inspiré de CUDA. Elles appellent des bibliothèques telles que cuBLAS, cuFFT, cuSPARSE et cuDNN, tout en dépendant de comportements spécifiques de l’environnement d’exécution.
Cet ensemble logiciel accumulé crée des coûts de changement. L’achat d’un GPU différent ne rend pas automatiquement portable un programme Windows ciblant CUDA.
Les développeurs disposent généralement de trois grandes options. Ils peuvent rester sur du matériel NVIDIA, porter le programme vers une autre interface ou placer une couche de traduction entre l’application et le matériel.
AMD prend en charge la voie du portage via HIP. Ses outils HIPIFY traduisent de nombreuses constructions de code source CUDA en C++ HIP portable.
La conversion du code source peut constituer un choix solide à long terme lorsque les développeurs contrôlent l’application. Elle exige également des tests, de la maintenance et parfois des modifications manuelles autour d’API non prises en charge.
Cette voie aide peu un utilisateur qui ne possède qu’un binaire Windows compilé. Elle crée également du travail pour les petites équipes qui maintiennent des dépendances spécifiques à CUDA.
ZLUDA cible cette lacune. Il tente de préserver l’interface orientée CUDA attendue par l’application tout en traduisant les opérations à l’exécution.
Cette approche ressemble davantage à un pont de compatibilité qu’à une nouvelle norme de programmation. L’application continue de parler CUDA, tandis que le pont associe les requêtes prises en charge à la pile logicielle d’AMD.
Windows rend le problème particulièrement pertinent. AMD y a étendu sa prise en charge du calcul GPU, mais sa pile Windows a historiquement exposé moins de composants que ROCm sous Linux.
AMD décrit le SDK HIP pour Windows comme un sous-ensemble de la plateforme ROCm plus large. Ses matrices de prise en charge limitent également la couverture officielle aux systèmes d’exploitation et GPU répertoriés.
Les versions récentes de ROCm ont amélioré les options Windows natives, notamment la prise en charge de PyTorch sur certains matériels Radeon. La prise en charge native réduit le besoin de traduction lorsque les applications proposent déjà une voie AMD.
Pourtant, la prise en charge native de PyTorch ne résout pas toutes les dépendances CUDA. Une application Windows peut intégrer une version de LibTorch spécifique à CUDA ou charger directement des bibliothèques NVIDIA.
Le nouveau dépôt traite cette situation moins pratique. Sa motivation déclarée était une application d’entraînement LibTorch orientée CUDA qui devait fonctionner sur un GPU AMD de bureau.
Le projet indique que son application de test a achevé l’inférence, les mises à jour d’apprentissage par renforcement et le travail d’optimisation. Le réseau comptait 2 216 347 paramètres et a exécuté une itération de validation couvrant 65 536 pas de temps.
Ces chiffres décrivent une charge de travail réelle plutôt qu’une sonde d’API synthétique. Ils confèrent au projet plus de crédibilité qu’un lanceur qui se contente d’ouvrir une fenêtre d’application.
Le test reste néanmoins étroit. Un réseau d’apprentissage par renforcement relativement petit ne peut pas représenter tous les transformeurs, générateurs d’images, simulations scientifiques ou pipelines de rendu.
La pression de développement s’exerce le plus directement sur l’expérience logicielle Windows d’AMD. Chaque expérience de compatibilité réussie met en évidence la demande d’applications qui supposent encore CUDA.
NVIDIA fait également face à un autre type de pression. Les couches de traduction testent dans quelle mesure la base applicative de CUDA dépend d’interfaces essentielles qu’un autre environnement d’exécution peut reproduire.
Aucune de ces pressions ne produit un changement immédiat de plateforme. Elles montrent toutefois que les développeurs continuent de chercher des moyens de contourner les frontières applicatives propres aux fournisseurs.
Le mécanisme préserve les API, pas toute la plateforme CUDA
ZLUDA peut traduire certaines interfaces, mais les applications CUDA dépendent souvent de comportements qui dépassent largement ces interfaces.
Une application CUDA contient généralement du code hôte exécuté sur le CPU et du travail sur l’appareil exécuté sur le GPU. L’hôte alloue la mémoire, transfère les données et lance les noyaux.
Le binaire peut également appeler des bibliothèques optimisées. Ces bibliothèques déterminent souvent si une application d’IA ou scientifique fonctionne à une vitesse utile.
ZLUDA présente des remplacements pour les composants orientés CUDA et les relie à des backends non NVIDIA. Sur le matériel AMD, ces backends utilisent les bibliothèques HIP et ROCm.
Ce modèle peut bien fonctionner lorsqu’un programme reste dans les fonctions d’exécution implémentées et les bibliothèques associées. Il devient fragile lorsque l’application attend un comportement absent.
La compatibilité des versions ajoute une autre couche. Les applications CUDA peuvent cibler différents kits d’outils, formats binaires, bibliothèques et hypothèses de compilateur.
Le dépôt fixe ZLUDA v6 preview 69, le SDK HIP 6.4 d’AMD et LibTorch 2.3.0 avec CUDA 11.8. Le verrouillage des versions transforme une collection mouvante de dépendances en une combinaison testable.
Cette discipline améliore la reproductibilité. Elle signifie également que les utilisateurs ne doivent pas supposer que des composants plus récents sont interchangeables.
Un SDK HIP plus récent peut modifier les chemins de bibliothèques, les symboles exportés ou les cibles d’appareils prises en charge. Une application orientée CUDA plus récente peut appeler des fonctions que sa couche de compatibilité figée n’implémente pas.
Le projet indique que cuBLAS, cuBLASLt, cuSPARSE et cuFFT ont réussi sa vérification d’exécution. Ces composants couvrent d’importantes opérations de matrices, de calcul creux et de transformée de Fourier.
L’élément manquant le plus important est cuDNN. La bibliothèque CUDA Deep Neural Network de NVIDIA fournit des primitives optimisées utilisées par de nombreuses charges de travail de réseaux neuronaux.
Le dépôt indique que cuDNN n’est pas disponible avec sa configuration validée du SDK HIP stable pour Windows. Il note également que le SDK ne comprend pas la collection complète de bibliothèques ROCm AI disponible ailleurs.
Cette omission crée une frontière stricte pour les applications. Les logiciels fortement axés sur les convolutions et qui attendent cuDNN peuvent échouer, nécessiter une pile de développement plus récente ou demander un travail de compatibilité supplémentaire.
La charge de travail d’apprentissage par renforcement réussie n’a pas nécessité cuDNN dans son parcours testé. Les opérations de matrices denses étaient suffisantes pour les fonctions qu’elle a exercées.
Ce détail explique à la fois le résultat et ses limites. Le projet a sélectionné une charge de travail compatible avec les bibliothèques disponibles sur sa machine.
La traduction à l’exécution diffère aussi de la portabilité du code source. Le code source HIP peut être compilé et optimisé pour différents backends, tandis qu’une couche de compatibilité binaire doit déduire et rediriger un comportement existant.
Le travail au niveau du code source donne aux développeurs davantage de contrôle sur l’optimisation propre à l’architecture. La traduction offre un accès initial plus rapide lorsque modifier l’application d’origine est peu pratique.
Aucune méthode ne garantit des performances identiques. Les GPU diffèrent par leur largeur d’exécution, leur comportement mémoire, leur prise en charge des instructions et leur matériel spécialisé.
Une fonction traduite peut produire une sortie correcte tout en empruntant un chemin moins efficace. À l’inverse, une bibliothèque fournisseur associée peut offrir de bonnes performances, car AMD a déjà optimisé l’opération sous-jacente.
Cela explique pourquoi un seul benchmark ne peut pas trancher la question plus vaste des performances. La surcharge de traduction n’est qu’un facteur, tandis que le choix des bibliothèques et le comportement des noyaux peuvent dominer le temps d’exécution total.
Le dépôt a enregistré une comparaison contrôlée le 13 septembre 2026. Il a exécuté dix itérations par environnement d’exécution sur la même charge de travail d’apprentissage par renforcement RX 9060 XT.
Après avoir retiré la première itération d’échauffement de chaque essai, le chemin upstream a atteint une médiane rapportée de 13 278 étapes globales par seconde. Un overlay personnalisé récupéré a atteint 12 876.
Le dépôt calcule que l’overlay personnalisé était environ 3,03 % plus lent lors de ce test. Il conserve donc le chemin upstream public comme option par défaut.
Cette comparaison évalue deux configurations de compatibilité sur une même machine. Elle ne compare pas la carte Radeon à un GPU NVIDIA ni à une implémentation HIP native.
Les chiffres historiques du dépôt utilisaient une autre configuration d’entraînement. Ils ne peuvent pas être directement comparés au test contrôlé.
Pour les développeurs, le résultat utile est plus simple. Les composants publics ont achevé la charge de travail choisie sans fichiers binaires privés ou récupérés.
Cela rend la procédure plus facile à examiner et à reproduire. Des résultats indépendants sur d’autres matériels détermineront si elle devient davantage qu’une référence sur une seule machine.
Un seul GPU vérifié laisse subsister un important déficit de compatibilité
La configuration est une expérience étayée par des preuves, et non une prise en charge générale de CUDA pour les cartes Radeon.
La RX 9060 XT est actuellement le seul périphérique validé répertorié par le projet. Les scripts reconnaissent d’autres familles d’architectures AMD, mais les désignent comme candidates.
La matrice de prise en charge officielle d’AMD constitue une contrainte distincte. L’entreprise indique que les GPU absents de son tableau actuel ne sont pas officiellement pris en charge par la distribution Windows concernée.
Même un GPU répertorié ne bénéficie pas automatiquement de la validation du dépôt. La prise en charge officielle de HIP et la réussite d’un test de traduction CUDA évaluent différentes couches du système.
Un utilisateur a besoin d’un pilote AMD compatible, d’une installation HIP fonctionnelle, de bibliothèques prises en charge, d’un comportement correct de ZLUDA et d’une application restant dans le périmètre couvert par l’implémentation.
Une défaillance dans n’importe quelle couche peut produire une erreur ou un résultat incorrect. Certains problèmes apparaîtront durant l’installation, tandis que d’autres ne se manifesteront qu’après des calculs prolongés.
La correction mérite davantage d’attention que le simple lancement de l’application. Les charges de travail numériques peuvent s’achever tout en produisant des résultats différents en raison de la précision, des bibliothèques ou du comportement de l’implémentation.
Un plan de validation sérieux devrait comparer les résultats attendus, le comportement d’entraînement et la répétabilité. Il devrait également tester la pression mémoire, les longues exécutions et la récupération après erreur.
Le dépôt fournit des scripts et une charge de travail documentée, ce qui aide d’autres utilisateurs à entamer ce processus. La validation indépendante reste limitée, car le projet est récent et la couverture matérielle étroite.
ZLUDA décrit lui-même son logiciel comme un remplacement CUDA direct pour les GPU non-NVIDIA. Son dépôt public comporte également une longue liste de modifications d’implémentation et de versions preview.
Toutefois, une interface directe ne garantit pas une compatibilité comportementale complète. L’historique des versions de ZLUDA reflète des correctifs continus concernant les chargeurs, le comportement du compilateur, les types de données et la gestion des versions CUDA.
Les logiciels preview peuvent introduire des régressions. Un projet qui fixe une version fonctionnelle évite certaines évolutions, mais passe aussi à côté de correctifs de compatibilité ultérieurs.
Les logiciels de sécurité Windows créent un autre risque pratique. L’interception à l’exécution et la redirection de bibliothèques peuvent ressembler à des techniques utilisées par des logiciels malveillants.
Les utilisateurs ne devraient obtenir les binaires qu’à partir de versions upstream identifiées et vérifier les hachages. Ils ne devraient pas désactiver de larges contrôles de sécurité simplement pour forcer l’exécution d’un paquet inconnu.
La vérification des hachages du dépôt est utile dans ce contexte. Elle réduit le risque qu’un téléchargement modifié entre silencieusement dans l’environnement d’exécution.
Elle n’audite pas le code upstream et n’établit pas la sûreté de chaque dépendance. Les organisations devraient appliquer leurs procédures habituelles d’examen logiciel et de contrôle des artefacts.
Les licences méritent également une gestion attentive. Le dépôt comprend sa propre licence et des avis de tiers, tandis que ZLUDA utilise des licences open source.
CUDA reste une plateforme NVIDIA comprenant des composants propriétaires et des conditions de licence. Les utilisateurs doivent comprendre quels fichiers redistribuables leur application contient et ce que télécharge la configuration de compatibilité.
Le dépôt met l’accent sur un chemin reposant uniquement sur des composants upstream publics. Ce choix aide à distinguer la méthode actuelle d’anciens arrangements expérimentaux impliquant des bibliothèques récupérées ou privées.
Les équipes en entreprise font face à un autre problème : la responsabilité du support. AMD ne prend pas officiellement en charge une recette communautaire de compatibilité CUDA simplement parce qu’elle utilise le SDK HIP.
NVIDIA ne prend pas en charge les applications CUDA exécutées sur des GPU AMD. Le mainteneur du projet ne peut pas remplacer les engagements de service de l’un ou l’autre fournisseur.
Cette configuration est donc peu adaptée aux charges de travail exigeant une disponibilité garantie sans qualification interne approfondie. Elle reste plus attrayante pour les laboratoires, les amateurs et les développeurs qui testent la portabilité.
Les équipes qui l’évaluent devraient conserver les rapports de machine, les versions exactes des paquets, les résultats de validation et les journaux de l’application. Une base de connaissances d’ingénierie consultable peut maintenir ces artefacts liés à chaque test.
Elles devraient également isoler les tests des environnements de production. Une machine dédiée ou une image Windows jetable facilite le retour en arrière lorsque des pilotes ou bibliothèques entrent en conflit.
La question centrale n’est pas de savoir si un exemple se lance. Elle est de savoir si l’application exacte produit des résultats corrects et répétables sur le matériel requis par l’équipe.
Les couches de compatibilité soumettent l’avantage logiciel de CUDA à un nouveau test
Le projet remet en question, à la marge, le verrouillage applicatif de CUDA, tout en soulignant combien une compatibilité complète reste difficile.
L’avantage de NVIDIA comprend le matériel, les pilotes, les compilateurs, les outils de débogage, les bibliothèques optimisées, la documentation et des années d’intégration applicative. CUDA est l’interface reliant ces éléments.
Un projet de compatibilité peut reproduire certains appels sans reproduire tout cet environnement de développement. Cette différence explique pourquoi ces projets attirent l’attention avant d’atteindre une fiabilité étendue.
Pour AMD, la compatibilité offre un moyen d’atteindre des applications que les éditeurs n’ont pas portées. La prise en charge native de ROCm et HIP reste la voie la plus propre lorsque les développeurs maintiennent les deux backends.
Les deux stratégies peuvent coexister. La traduction sert les binaires CUDA existants, tandis que HIP prend en charge les logiciels conçus ou convertis pour un déploiement multi-fournisseurs.
DirectML et d’autres interfaces Windows offrent des alternatives supplémentaires. Elles peuvent fournir une accélération indépendante du fournisseur, mais les applications doivent les adopter explicitement.
OpenCL et SYCL visent également la portabilité à différents niveaux. Leur présence n’a pas supprimé les bibliothèques spécifiques à CUDA ni les hypothèses propres aux applications.
La discussion sur Hacker News a mis cette tension en évidence. Certains commentateurs ont soutenu que les standards ouverts méritent davantage d’attention, car les interfaces fermées limitent le choix matériel.
D’autres ont souligné que les interfaces portables offrent souvent une expérience développeur moins bonne. Une autre position critique estimait que l’optimisation spécifique au matériel empêche une couche générique unique d’égaler chaque fournisseur.
Les deux positions décrivent des contraintes réelles. Les développeurs veulent de la portabilité, mais les noyaux haute performance dépendent des détails d’architecture et de bibliothèques optimisées.
ZLUDA privilégie la compatibilité à la pureté. Il permet à l’application de conserver ses hypothèses orientées CUDA et traduit ce qu’il peut.
Cette approche réduit le travail initial de migration. Elle conserve également CUDA comme langage attendu par l’application, au lieu de le remplacer par un standard indépendant.
C’est le renversement central du projet. Exécuter un programme ciblant CUDA sur AMD peut affaiblir le verrouillage matériel tout en maintenant la dépendance logicielle à CUDA.
Si davantage d’applications fonctionnent, CUDA pourrait devenir une interface largement ciblée dont les binaires atteignent plusieurs backends. Ce résultat exercerait une pression sur l’exclusivité matérielle de NVIDIA.
Si la compatibilité reste spécifique à chaque charge de travail, les expériences pourront au contraire démontrer la profondeur de l’intégration logicielle de NVIDIA. Chaque bibliothèque manquante devient une raison supplémentaire pour les développeurs de rester sur du matériel CUDA pris en charge.
Les progrès natifs d’AMD sous Windows modifient le calcul. De meilleures bibliothèques HIP et une prise en charge PyTorch plus large offrent une base plus solide aux projets de traduction.
Ils réduisent également le besoin de traduction lorsque les applications peuvent adopter les paquets AMD officiels. Il s’agit d’un chevauchement sain, pas nécessairement d’un conflit.
Le signal concurrentiel important sera le comportement des applications. Les matrices de prise en charge comptent, mais les utilisateurs vivent la compatibilité à travers des programmes qui s’installent, terminent leur travail et renvoient des résultats corrects.
Une liste de noms d’API traduits ne peut se substituer à ces preuves. Un benchmark isolé sans implémentation native comparable ne le peut pas davantage.
Les futurs rapports les plus utiles décriront la version de l’application, le GPU, le pilote, le SDK HIP, la version de ZLUDA, les bibliothèques sollicitées, les vérifications de sortie et les performances prolongées.
Les rapports négatifs seront tout aussi importants. Un échec documenté identifie la fonction manquante ou l’hypothèse incompatible que les mainteneurs doivent traiter.
Ces éléments peuvent également guider les éditeurs d’applications. Des échecs répétés autour d’une dépendance peuvent justifier un backend HIP natif ou un autre chemin d’exécution portable.
Le dépôt importe donc même s’il ne devient jamais un environnement d’exécution universel. Il crée une surface de test reproductible pour mesurer où commence et où s’arrête la dépendance à CUDA.
Trois signaux détermineront la suite
Des rapports matériels plus larges, une couverture de bibliothèques plus profonde et des résultats applicatifs stables décideront si cela devient une option pratique sous Windows.
Le premier signal est une validation indépendante sur d’autres GPU Radeon. Le résultat de la RX 9060 XT doit être reproduit sur du matériel RDNA3 et RDNA4 officiellement pris en charge.
Les rapports positifs devraient inclure les versions exactes et des vérifications de sortie. Une simple capture d’écran ou le nom d’un périphérique détecté n’établira pas la compatibilité avec une charge de travail.
Plusieurs résultats cohérents renforceraient l’affirmation selon laquelle la configuration est portable sur les périphériques Windows d’AMD. Des échecs fréquents spécifiques à une architecture la réduiraient à une configuration de référence.
Le deuxième signal est la couverture de cuDNN ou d’un équivalent pour les réseaux neuronaux. De nombreuses applications d’IA reposent sur des opérations que la pile stable validée ne fournit pas actuellement par cette voie.
La prise en charge pourrait venir d’une distribution HIP plus récente, de mappages ZLUDA ajoutés, de modifications applicatives ou d’un autre pont de bibliothèques. Chaque voie entraîne des coûts de maintenance différents.
Le fonctionnement d’applications fortement axées sur les convolutions élargirait sensiblement la pertinence du projet. Leur absence persistante laisserait de nombreuses charges de travail d’image et de modèles hors de sa portée pratique.
Le troisième signal est la stabilité face aux mises à jour des applications et des toolkits. Le succès actuel dépend de versions figées de ZLUDA, HIP et LibTorch orienté CUDA.
Les développeurs devraient surveiller si les versions ultérieures de ZLUDA préservent le test, si les nouveaux paquets HIP pour Windows restent compatibles et si les applications plus récentes introduisent des appels non pris en charge.
Un projet de compatibilité gagne en valeur lorsque les mises à niveau n’exigent pas de redécouvrir une combinaison fragile. Des régressions indiqueraient que l’approche nécessite toujours une maintenance manuelle intensive.
Dans cette évaluation, les performances devraient venir après la correction. Une application traduite qui renvoie parfois des résultats erronés a peu de valeur, quel que soit son débit.
Après la correction, les comparaisons devraient inclure une compilation HIP native lorsqu’elle existe. Elles devraient aussi utiliser des paramètres applicatifs équivalents et le même matériel.
Les comparaisons avec NVIDIA peuvent répondre à une question d’achat, mais elles n’isolent pas la surcharge de traduction. L’architecture GPU, la capacité mémoire et les bibliothèques du fournisseur peuvent toutes influer sur le résultat.
Le projet actuel a déjà franchi un seuil significatif. Il a transformé un ensemble de composants upstream en une procédure Windows répétable et a achevé la charge de travail qui le motivait.
Il n’a pas encore franchi le seuil que son titre mémorable laisse entendre. CUDA pour AMD sous Windows reste une promesse de compatibilité liée à des logiciels précis et à un seul GPU validé.
Les développeurs souhaitant le tester devraient commencer par les versions et scripts de diagnostic documentés dans le dépôt. Avant toute installation, ils devraient vérifier leur GPU dans la liste de prise en charge actuelle d’AMD.
Ensuite, ils devraient choisir une charge de travail dont le résultat de référence est connu et correct. Cette référence compte davantage que le fait que le programme détecte un appareil nommé CUDA.
Les équipes devraient consigner les échecs et publier, lorsque cela est possible, des rapports de compatibilité reproductibles. Les preuves partagées permettront de déterminer si le pont prend en charge une catégorie d’applications ou seulement des exemples isolés.
La question plus large prend désormais une forme mesurable : quelle part des logiciels CUDA peut migrer vers du matériel AMD sans modification du code source, et quels éléments échouent en premier ?
Au cours des prochains mois, surveillez la matrice de compatibilité, les progrès liés à cuDNN et les résultats d’applications Windows réelles. Ces signaux détermineront si CUDA pour AMD sous Windows devient fiable ou demeure une expérience instructive.
