La Lettre IT
#4971763817 sept.
Débat partagé, dominé par deux tensions : admiration technique d'un côté, préoccupations juridiques et éthiques de l'autre. Plusieurs commentateurs relèvent que l'auteur est ancien ingénieur Apple, ce qui complique potentiellement l'acceptation en amont. La politique stricte d'Asahi Linux contre les LLM crée un fossé explicite. Pas de consensus sur la faisabilité de l'intégration noyau Linux.

Un développeur construit un pilote GPU Linux pour le M4 en un mois grâce aux LLM

  • Un développeur ex-Apple a construit en quatre semaines un pilote OpenGL ES 3.0 entièrement fonctionnel pour le GPU M4 du Mac mini et du MacBook Neo, en s'appuyant sur un hyperviseur maison et des LLM pour l'ingénierie inverse.
  • Le pilote tourne assez vite pour faire tourner Minecraft à 200 fps et exécuter Chrome ou Firefox avec WebGL.
  • Le code n'est pas encore prêt pour les utilisateurs finaux, mais représente un raccourci massif par rapport aux années normalement nécessaires pour développer un pilote GPU.
  • Deux questions dominent le débat : la légitimité juridique et éthique d'utiliser des LLM pour ce reverse engineering, et l'acceptation en amont (noyau Linux, Asahi Linux) face à ces considérations.

Ce que dit la source

L'auteur affirme avoir livré un pilote GPU entièrement conforme à OpenGL ES 3.0 pour le M4 (A18 Pro et M5 en grande partie) en environ un mois. Normalement, cette tâche demande des années. Le pilote a été construit par reverse engineering de la firmware AGX d'Apple et des composants en espace utilisateur, en s'appuyant sur un hyperviseur précédemment développé pour capturer des traces du matériel. L'auteur insiste sur le respect d'une approche « clean room » : aucun binaire Apple examiné, seulement des traces matérielles et des shaders générés localement. Pour accélérer l'ingénierie inverse, il a utilisé un LLM (vraisemblablement Codex) pour systématiser le processus de rejoue des états GPU capturés et reconstruire les structures de données sous-jacentes.

  • L'ABI firmware AGX s'est révélée bien plus complexe que celle du M1/M2 (1,5× plus de structures, 2× plus de pointeurs, processus de soumission de travail significativement plus tortueux).
  • L'auteur a documenté deux approches : capturer le comportement de macOS via l'hyperviseur, rejouer l'état, puis reconstruire progressivement en espace utilisateur sans état rejoué.
  • Le LLM a pris l'approche de replay « extrêmement littéralement » : il sauvegardait l'état complet de la mémoire GPU après les premiers événements firmware visibles, les restaurait après redémarrage, puis réduisait itérativement le nombre de pages copiées jusqu'à zéro.
  • Trois obstacles majeurs ont surgi autour de l'incapacité à capturer proprement le travail hôte une fois que la firmware a démarré, forçant à investiguer différentes stratégies.
  • Le code n'est pas encore produit pour les utilisateurs finaux ; l'intention affichée est de le rendre accessible dès que possible.

Dans les commentaires

Débat partagé, dominé par deux tensions : admiration technique d'un côté, préoccupations juridiques et éthiques de l'autre. Plusieurs commentateurs relèvent que l'auteur est ancien ingénieur Apple, ce qui complique potentiellement l'acceptation en amont. La politique stricte d'Asahi Linux contre les LLM crée un fossé explicite. Pas de consensus sur la faisabilité de l'intégration noyau Linux.

  • Le statut d'ancien ingénieur Apple de l'auteur est mis en avant par plusieurs commentateurs comme obstacle possible à l'acceptation du noyau Linux et source de conflit potentiel, surtout au vu des litiges entre Apple et OpenAI autour de la propriété intellectuelle.
  • Asahi Linux maintient une politique explicitement hostile aux LLM ; l'auteur a aussi apparemment dissimulé son usage extensif de LLM dans une tentative de contribution antérieure, ce qui a mené à son exclusion du projet.
  • L'utilisation de Codex (outil OpenAI) soulève des questions de traçabilité : personne ne sait précisément ce qu'OpenAI a utilisé pour entraîner ce modèle, notamment face aux accusations d'Apple contre OpenAI.
  • Quelques commentateurs notent que la valeur réelle dépend de la qualité du pilote produit et de sa stabilité, inconnues pour le moment.
  • Un commentateur signale avoir lui-même réussi la même chose sur M3 avant cette publication, remettant en question l'exclusivité technique de l'approche.

Notre lecture

Accomplissement technique remarquable en rétrécissement de délai, qui montre où les LLM peuvent accélérer des tâches nécessitant une exploration systématique d'un espace de configuration massif. Mais l'intégration en amont n'est pas du tout certaine : les blocages ne sont pas techniques, ce sont des questions de provenance (ancien employé Apple, entraînement OpenAI contesté, politique des projets établis). Le driver restera probablement utilisable mais parallèle aux chaînes officielles, du moins à court terme. Pour une DSI évaluant l'impact : aucune action immédiate, mais à surveiller pour voir si la démonstration catalyse un changement de politique chez Asahi ou un débat plus large au sein de la communauté Linux sur les LLM et les reverse engineering assistés.

Le brief, dans votre boîte mail

Recevez chaque jour la sélection et l'analyse La Lettre IT, sans avoir à repasser sur le site.

En vous inscrivant, vous consentez à recevoir la newsletter quotidienne La Lettre IT. Désabonnement en un clic à tout moment.