Le Framework mlX d'IA Apple maintenant compatible avec les GPU nVidia, Réactions à la publication du 22/07/2025

[Paul Emploi]

Je vous avais parlé du Framework mlX d'Apple, open-source et initialement uniquement destiné aux Mac ARM quoique portable sur Mac Intel, et utilisant Metal.

Il permet de faire des développements d'IA sur Mac, mais bien qu'il indiquait "datacenter", ne tournait que sur Mac, et initialement développé pour Mac ARM.

Voilà qu'il dispose maintenant d'un backend (étage de sortie) capable de générer du code cuda, permettant au code de s'exécuter sur les GPU nVidia, y-compris en datacenter (enfin) ou dans le cloud.

Une ouverture bienvenue mais à mon avis insuffisante pour transformer les Mac en machines de développement d'IA destinées à tourner sous cuda dans les datacenter...

Lien vers le billet original

[linus]

Si je comprends bien, même Apple a laissé tombé OpenCL. Il y a quelques années, l'un des principaux développeur d'un logiciel de dynamique moléculaire, BigDFT pratiquant à haute dose le calcul GPU pour accélérer des calculs monstrueux, m'expliquait que, si on aboutissait au même résultat avec les deux, OpenCL était infiniment mieux programmé, bien plus facile à utiliser que Cuda. Est ce que, une fois encore, ce n'est pas le meilleur langage qui gagne pour des raisons externes au Language lui-même ? (dans ce cas, la puissance de Nvidia.

[Paul Emploi]

Si je comprends bien, même Apple a laissé tombé OpenCL. Il y a quelques années, l'un des principaux développeur d'un logiciel de dynamique moléculaire, BigDFT pratiquant à haute dose le calcul GPU pour accélérer des calculs monstrueux, m'expliquait que, si on aboutissait au même résultat avec les deux, OpenCL était infiniment mieux programmé, bien plus facile à utiliser que Cuda. Est ce que, une fois encore, ce n'est pas le meilleur langage qui gagne pour des raisons externes au Language lui-même ? (dans ce cas, la puissance de Nvidia.

Apple n'a pas laissé tomber OpenCL, qui est encore supporté dans nos Mac et dont il avait été le créateur avant de le confier au Khronos Group.

En revanche cuda ne cible que les architectures cuda de nVidia et évolue conjointement avec celles-ci en étant optimisées pour elles.
OpenCL suit de plus loin, pas vraiment optimisé nulle part (et surtout pas chez nVidia): c'est portable mais les performances sont inférieures sur du nVidia.
Apple cible Metal et plus OpenCL, là aussi pour des raisons de performances.

En résumé openCL est mort, car trop lent. Trop lent à évoluer. Trop lent à s'exécuter sur les plateformes cuda ou Mac.

[linus]

Si je comprends bien, même Apple a laissé tombé OpenCL. Il y a quelques années, l'un des principaux développeur d'un logiciel de dynamique moléculaire, BigDFT pratiquant à haute dose le calcul GPU pour accélérer des calculs monstrueux, m'expliquait que, si on aboutissait au même résultat avec les deux, OpenCL était infiniment mieux programmé, bien plus facile à utiliser que Cuda. Est ce que, une fois encore, ce n'est pas le meilleur langage qui gagne pour des raisons externes au Language lui-même ? (dans ce cas, la puissance de Nvidia.

Apple n'a pas laissé tomber OpenCL, qui est encore supporté dans nos Mac et dont il avait été le créateur avant de le confier au Khronos Group.

En revanche cuda ne cible que les architectures cuda de nVidia et évolue conjointement avec celles-ci en étant optimisées pour elles.
OpenCL suit de plus loin, pas vraiment optimisé nulle part (et surtout pas chez nVidia): c'est portable mais les performances sont inférieures sur du nVidia.
Apple cible Metal et plus OpenCL, là aussi pour des raisons de performances.

En résumé openCL est mort, car trop lent. Trop lent à évoluer. Trop lent à s'exécuter sur les plateformes cuda ou Mac.

"avant de le confier au Khronos Group" C'est fou le nombre de logiciels prometteurs conçus par la pomme et dont elle se débarrasse au moment où ça devient intéressant ou qui meurent faute de suivi après des débuts en fanfare à la WWDC. Quel incroyable manque de constance dans ce domaine. Je n'arrive pas à croire que ce soit là de la bonne gestion.

[aranaud]

... Quel incroyable manque de constance dans ce domaine...

Je dirai que tu résumes parfaitement la politique d'Apple.

La création soit disant de technologie révolutionnaire imparfaite/non finie/verrouiller. Elles sont rapidement abandonné si sa ne rapport pas de la thune ou contraint par les bureaucrates. Dans la même veine que le sujet "Apple aurait voulu concurrencer Amazon AWS". La question est plutôt comment un industriel pourrait fait confiance sur le long terme avec une entreprise comme Apple.

Ce message a été modifié par aranaud - 27 Jul 2025, 09:26.

[Paul Emploi]

Si je comprends bien, même Apple a laissé tombé OpenCL. Il y a quelques années, l'un des principaux développeur d'un logiciel de dynamique moléculaire, BigDFT pratiquant à haute dose le calcul GPU pour accélérer des calculs monstrueux, m'expliquait que, si on aboutissait au même résultat avec les deux, OpenCL était infiniment mieux programmé, bien plus facile à utiliser que Cuda. Est ce que, une fois encore, ce n'est pas le meilleur langage qui gagne pour des raisons externes au Language lui-même ? (dans ce cas, la puissance de Nvidia.

Apple n'a pas laissé tomber OpenCL, qui est encore supporté dans nos Mac et dont il avait été le créateur avant de le confier au Khronos Group.

En revanche cuda ne cible que les architectures cuda de nVidia et évolue conjointement avec celles-ci en étant optimisées pour elles.
OpenCL suit de plus loin, pas vraiment optimisé nulle part (et surtout pas chez nVidia): c'est portable mais les performances sont inférieures sur du nVidia.
Apple cible Metal et plus OpenCL, là aussi pour des raisons de performances.

En résumé openCL est mort, car trop lent. Trop lent à évoluer. Trop lent à s'exécuter sur les plateformes cuda ou Mac.

"avant de le confier au Khronos Group" C'est fou le nombre de logiciels prometteurs conçus par la pomme et dont elle se débarrasse au moment où ça devient intéressant ou qui meurent faute de suivi après des débuts en fanfare à la WWDC. Quel incroyable manque de constance dans ce domaine. Je n'arrive pas à croire que ce soit là de la bonne gestion.

Non non, c'est l'inverse: OpenCL a été créé par Apple et y était limité dans les faits.
En le confiant à Khronos Group, c'est devenu libre de droits, totalement open-source, avec un développement communautaire!
Apple continuant à implémenter des drivers OpenCL dans ses Mac, mais OpenCL finissant par être aussi implémenté du coté AMD/ATI, nVidia, Intel, etc.

OpenCL est encore supporté aujourd'hui dans nos Mac les plus récents, mais Metal est l'alternative propriétaire d'Apple, conçu pour ses GPU, pour être justement proche du métal et non une couche d'abstraction, et est bien plus performant grâce à cela.

La grande force de OpenCL est d'être portable et supporté sur quasi toutes les architectures GPU et CPU (via leurs unités vectorielles).
Celle de cuda est d'exploiter au maximum les GPU nVidia, y-compris le plus récent Blackwell, avec des outils de grande qualité pour les développeurs, du PC avec une Geforce jusqu'aux Datacenters, que ça soit pour le HPC ou l'IA.
Et celle de Metal est d'exploiter les SoC des Mac récents à 100%.

En renversant la proposition:
Créer un logiciel PC, Mac et Linux exploitant toutes leurs capacités de calculs vectoriels dont leurs GPU : OpenCL.
Créer un logiciel spécialisé destiné à aller dans des datacenters: cuda.
Créer un logiciel pour mac (et uniquement Mac) : Metal.

[Benzebut]

Non non, c'est l'inverse: OpenCL a été créé par Apple et y était limité dans les faits.
En le confiant à Khronos Group, c'est devenu libre de droits, totalement open-source, avec un développement communautaire!
Apple continuant à implémenter des drivers OpenCL dans ses Mac, mais OpenCL finissant par être aussi implémenté du coté AMD/ATI, nVidia, Intel, etc.

OpenCL est encore supporté aujourd'hui dans nos Mac les plus récents, mais Metal est l'alternative propriétaire d'Apple, conçu pour ses GPU, pour être justement proche du métal et non une couche d'abstraction, et est bien plus performant grâce à cela.

La grande force de OpenCL est d'être portable et supporté sur quasi toutes les architectures GPU et CPU (via leurs unités vectorielles).
Celle de cuda est d'exploiter au maximum les GPU nVidia, y-compris le plus récent Blackwell, avec des outils de grande qualité pour les développeurs, du PC avec une Geforce jusqu'aux Datacenters, que ça soit pour le HPC ou l'IA.
Et celle de Metal est d'exploiter les SoC des Mac récents à 100%.

En renversant la proposition:
Créer un logiciel PC, Mac et Linux exploitant toutes leurs capacités de calculs vectoriels dont leurs GPU : OpenCL.
Créer un logiciel spécialisé destiné à aller dans des datacenters: cuda.
Créer un logiciel pour mac (et uniquement Mac) : Metal.

Ou autre hypothèse, Apple n'a plus besoin d'OpenCL, qui était universelle pour les différentes cartes graphiques. Mais simplement désormais d'une version allégée mais adaptée à ses nouveaux processeurs intégrés, comme Cuba pour les GPU nVidia d'ailleurs. D'où sa généreuse donation à la communauté pour continuer les développements par le Khronos Group.

Avec l'actuelle génération de processeurs Apple Sillicon, qui avait du être envisagée il y a quelque temps en interne, seule des instructions pour ces familles de SoC sont requises pour aller au plus proche du métal et optimiser les rendus, d'où l'usage des bibliothèques Metal pour tout l’écosystème Apple (Mac, iOS, iPadOs, visionOs & watchOS) d'ailleurs.

[Paul Emploi]

Non. Regarde les dates.

Le transfert à Khronos Group a débuté en 2008, quand la transition aux Mac Intel se terminait...

[Benzebut]

Non. Regarde les dates.

Le transfert à Khronos Group a débuté en 2008, quand la transition aux Mac Intel se terminait...

Justement l'ingénierie interne semble logique dans la conception des uns et l'abandon des autres.

D’après Wikipedia, le Kronos Group à partir des travaux d'Apple, a publié fin 2008 la version stable 1.1 pour OpenCL multiplateforme. Suivit par Apple en 2009 dans sa version Mac OS X Snow Leopard.
La première génération d'Apple Slilicon "modestes" date de 2007 sur l'iPhone original et iPad, iPod touch et l'Apple TV ensuite. La version "acceptable" serait le A4 des premiers iPhones 4 en janvier 2010...

Bref, la gamme Apple commençait a basculer sur cette architecture ARM en interne, alors que l’intérêt pour des bibliothèques graphiques génériques disparaissait et cela le fut totalement avec le M1 avec le développement de Metal...

[Paul Emploi]

Bref, la gamme Apple commençait a basculer sur cette architecture ARM en interne, alors que l’intérêt pour des bibliothèques graphiques génériques disparaissait et cela le fut totalement avec le M1 avec le développement de Metal...

Metal n'a rien à voir avec ARM. Encore faux.

[Benzebut]

Metal n'a rien à voir avec ARM. Encore faux.

Mon cher Paul Emploi, il faudrait un peu de cohérence dans ces propos. Encore une fois suivant ces passionnants échanges :

Créer un logiciel PC, Mac et Linux exploitant toutes leurs capacités de calculs vectoriels dont leurs GPU : OpenCL.
Créer un logiciel spécialisé destiné à aller dans des datacenters: cuda.
Créer un logiciel pour mac (et uniquement Mac) : Metal.

Or les Mac fonctionnent principalement sous et bientôt uniquement sous l'architecture ARM par les processeurs Apple Silicon. Metal sous macOS étant la bibliothèque graphique de référence. Donc la version Metal 4 ne fonctionne déjà que sous ARM et a abandonné l'architecture Intel...

[Paul Emploi]

Metal n'a rien à voir avec ARM. Encore faux.

Mon cher Paul Emploi, il faudrait un peu de cohérence dans ces propos. Encore une fois suivant ces passionnants échanges :

Créer un logiciel PC, Mac et Linux exploitant toutes leurs capacités de calculs vectoriels dont leurs GPU : OpenCL.
Créer un logiciel spécialisé destiné à aller dans des datacenters: cuda.
Créer un logiciel pour mac (et uniquement Mac) : Metal.

Or les Mac fonctionnent principalement sous et bientôt uniquement sous l'architecture ARM par les processeurs Apple Silicon. Metal sous macOS étant la bibliothèque graphique de référence. Donc la version Metal 4 ne fonctionne déjà que sous ARM et a abandonné l'architecture Intel...

Metal n'a rien à voir avec ARM: Metal cible les GPU. Les GPU ne sont pas "x86" ou "ARM".
Et Metal fonctionne très bien sur les Mac Intel.

Tu peux essayer de distordre les choses comme tu veux, ce que tu viens d'écrire est encore faux.

[Benzebut]

Metal n'a rien à voir avec ARM: Metal cible les GPU. Les GPU ne sont pas "x86" ou "ARM".
Et Metal fonctionne très bien sur les Mac Intel.

Tu peux essayer de distordre les choses comme tu veux, ce que tu viens d'écrire est encore faux.

Non point. Bien sûr que les bibliothèques Metal sont pour les CPU, puisque ce sont bibliothèques graphiques pour ces composants.
Par contre, seules les précédentes versions de Metal fonctionnaient sous différents environnements pour les architectures Intel et ARM, la version Metal 4 a déjà abandonné la première.
Simplement parce que les bibliothèques Metal ne sont plus développées sous macOS que pour les processeurs Apple, qui sont sous architecture ARM incluant leurs propres CPU actuellement...

Et des développements de Metal restent possibles pour d'autres environnements en théorie, au cas d'un nouveau changement d'architecture. L'avenir dira ce qu'il en est...