SysadminNews

Asahi Linux approche d'une version M3, sans le GPU

Sur cette page
  1. Ce qui fonctionne aujourd'hui sur M3
  2. Les deux réserves
  3. Pourquoi le noyau principal avance plus lentement que le travail
  4. Où en sont M4 et M5
  5. Notre lecture
  6. Sources et pour aller plus loin

Asahi Linux a publié un rapport d'avancement le mercredi 26 août 2026 indiquant que le projet est assez proche pour publier une version officielle prenant en charge les Mac Apple M3. La liste de ce qui fonctionne désormais est plus longue que ne l'imagineraient la plupart des gens qui suivent le projet : webcams sur toute la gamme M3, microphones, USB 3.0, Thunderbolt, décodage matériel pour H.264, H.265, VP9 et AV1, et un affichage presque au niveau des M1 et M2. Les deux réserves comptent autant que la liste. Il s'agit de code aval et non du noyau Linux principal, donc un noyau de distribution ordinaire ne fera pas fonctionner ces machines. Et le GPU n'en fait pas partie. Si vous hésitez à mettre Linux sur un Mac M3, ce second point résume toute la décision.

The short answer

Asahi Linux a annoncé le 26 août 2026 être proche d'une version officielle prenant en charge les Mac Apple M3. Les webcams fonctionnent sur toute la gamme M3, les microphones aussi, l'USB 3.0 et le Thunderbolt fonctionnent, le décodage vidéo matériel couvre H.264, H.265, VP9 et AV1, et l'affichage est presque au niveau des M1 et M2. Il s'agit de code aval, pas du noyau Linux principal. Le GPU reste absent, et la gestion de l'énergie du processeur doit passer par une conformité PSCI via les services d'exécution UEFI avant de pouvoir remonter en amont.

26 aoûtrapport annonçant une version proche
4 codecsdécodés en matériel : H.264, H.265, VP9, AV1
Pas de GPUla pièce toujours manquante sur M3
Carte réponse résumant l'avancement d'Asahi Linux sur M3 : une version officielle prenant en charge les Mac Apple M3 approche, en code aval plutôt que dans le noyau Linux principal, avec webcams, microphones, USB 3.0, Thunderbolt et décodage vidéo matériel fonctionnels, un affichage presque au niveau des M1 et M2, et la prise en charge du GPU toujours absente.
Asahi Linux sur M3, en résumé. PNG

Ce qui frappe dans les rapports d'avancement d'Asahi, c'est à quel point les victoires sont devenues banales. Webcam. Microphone. USB 3. Ce sont les derniers dix pour cent, et les derniers dix pour cent sont l'endroit où un portage matériel cesse d'être une démonstration.

Ce qui fonctionne aujourd'hui sur M3

Le rapport du 26 août décrit la prise en charge M3 comme assez proche d'une version officielle, et la liste qui l'accompagne est fournie.

Les webcams fonctionnent sur les Mac de la série M3 qui en possèdent une, le M3 Max ayant demandé un petit ajustement de pilote qui lui est propre. Les microphones fonctionnent, ce qui a coûté plus d'efforts qu'il n'y paraît puisque Apple a changé le matériel audio pour cette génération et que les pilotes M1 et M2 ne se reportaient pas simplement. L'USB 3.0 et le Thunderbolt sont opérationnels. Le décodage vidéo matériel couvre H.264, H.265, VP9 et AV1. L'affichage est décrit comme presque au niveau des systèmes M1 et M2.

Carte liste de contrôle de la prise en charge matérielle des Apple M3 dans Asahi Linux : webcams fonctionnelles sur toute la gamme après un ajustement de pilote sur M3 Max, microphones fonctionnels après une nouvelle rétroconception audio, USB 3.0 et Thunderbolt fonctionnels, décodage matériel H.264 H.265 VP9 et AV1, affichage presque au niveau des M1 et M2, GPU et gestion de l'énergie en amont toujours manquants.
Où en est la prise en charge M3, fonction par fonction. PNG

Rapprochez cette liste de ce dont un portable a réellement besoin et l'écart est mince. Matériel de visioconférence, ports, écran, lecture vidéo. Pour une machine utilisée comme poste de développement, l'essentiel de l'usage quotidien est couvert.

Les deux réserves

Reste le GPU, qui ne figure pas dans la liste.

Sans pilote GPU, le rendu se fait sur le processeur. Un terminal et un éditeur, cela va. Un bureau moderne qui compose en haute résolution, non, et cela ne va pas d'une manière bien précise : celle qui coûte de l'autonomie sur une machine dont l'autonomie est l'argument principal. Le décodage vidéo matériel adoucit la situation plus qu'on ne l'attendrait, puisque la lecture est la charge que tout le monde imaginait la pire, mais tout ce qui touche à la 3D ou au calcul GPU est simplement indisponible.

La seconde réserve est qu'il s'agit de code aval. La version dont il est question embarque les correctifs du projet, pas ce que vous obtenez d'un noyau de distribution standard. Faire tourner un noyau Fedora ou Debian ordinaire sur un Mac M3 ne vous donne rien de ce qui précède.

Pourquoi le noyau principal avance plus lentement que le travail

L'histoire de la gestion de l'énergie illustre le mieux la distance entre l'aval et l'amont.

Asahi gère l'énergie du processeur avec un pilote Linux spécifique à Apple. L'ARM64 principal n'en veut pas : il attend que la gestion de l'énergie passe par PSCI, l'interface de coordination des états d'alimentation, standard que le reste du monde ARM64 implémente. La prise en charge de l'attente d'interruption profonde n'existe aujourd'hui que dans l'arbre aval pour cette raison.

La voie retenue consiste à implémenter la conformité PSCI via les services d'exécution UEFI, pour que le noyau voie une interface standard pendant que le mécanisme réel d'Apple se tient derrière. C'est plus de travail que de livrer le pilote, et c'est le bon choix, parce que l'alternative serait une exception permanente en forme d'Apple dans un sous système dont dépend toute machine ARM64.

C'est le rythme habituel du projet. Éprouver en aval, puis retravailler en quelque chose que la communauté du noyau acceptera. La seconde étape est régulièrement plus longue que la première, ce qui explique que la situation en amont soit toujours en retard sur les rapports d'avancement. L'amont a d'ailleurs progressé en parallèle, avec notamment l'activation des M3 Pro, Max et Ultra arrivée dans Linux 7.3.

Où en sont M4 et M5

Beaucoup plus tôt. Le rapport cite l'activation du stockage NVMe et des améliorations PCIe comme chantiers en cours, et décrit la mise en route comme incomplète avec d'autres difficultés devant.

Cela mérite d'être pris au pied de la lettre. Chaque génération a demandé une longue course pour atteindre le point où M3 se trouve maintenant, et le GPU a traîné derrière le reste à chaque fois. Acheter un Mac M4 ou M5 aujourd'hui parce que Linux y tournera un jour, c'est parier sur un calendrier que personne n'a annoncé.

Notre lecture

Si vous avez un Mac M3 qui dort et que vous voulez en faire une machine Linux, le moment raisonnable approche, à condition d'avoir compris la réserve sur le GPU au lieu de la survoler. Attendez l'annonce de la version plutôt que d'installer depuis des branches, sauf si suivre le projet est justement le but.

Si vous choisissez du matériel pour Linux, rien de tout cela ne fait d'un portable Apple la réponse sensée. L'exploit ici est qu'une petite équipe a rétroconçu une plateforme non documentée jusqu'à obtenir des webcams et du Thunderbolt fonctionnels, ce qui est remarquable. Ce n'est pas la même chose qu'une machine prise en charge. Pour du travail multiplateforme dans l'autre sens, nous avions regardé l'exécution de binaires macOS sur Linux ARM64 plus tôt cette année.

Sources et pour aller plus loin

Questions fréquentes

Puis je installer Asahi Linux sur un Mac M3 aujourd'hui ?

Vous pouvez le faire tourner, mais la version officielle n'est pas sortie et ce qui existe relève du code aval. Le rapport d'août dit que le projet est assez proche d'une version officielle pour M3, ce qui n'est pas la même chose que la version publiée. En pratique, installer aujourd'hui suppose de suivre les branches du projet plutôt qu'un chemin d'installation pris en charge, et de vivre avec ce qui est en cours de modification telle ou telle semaine. Si votre intérêt est la curiosité ou la contribution, c'est un endroit raisonnable où se trouver. Si vous avez besoin que la machine fonctionne lundi, attendez l'annonce de la version, parce que l'écart entre une version proche et une version publiée, c'est précisément le polissage qui rend un installateur sûr pour qui ne lit pas les journaux de commits.

Que signifie concrètement l'absence de prise en charge du GPU ?

Cela signifie que le rendu retombe sur le logiciel, ce qui reste praticable pour un terminal et un éditeur de texte et devient pénible pour tout le reste. Une session de bureau compose, défile et redessine, et faire tout cela sur le processeur coûte à la fois en réactivité et en autonomie, sur une machine achetée en grande partie pour son efficacité. La vidéo est l'exception intéressante : le décodage matériel de H.264, H.265, VP9 et AV1 fonctionne, donc la lecture n'est pas le désastre qu'on pourrait attendre en l'absence de pilote GPU. Mais tout ce qui touche à la 3D, au calcul GPU ou à un compositeur qui travaille vraiment est hors de portée. Rétroconcevoir un GPU non documenté fait partie des tâches les plus ardues de ce projet, et c'est systématiquement la dernière pièce à arriver pour chaque génération.

Pourquoi ce code reste il en aval plutôt que dans le noyau principal ?

Parce que le noyau principal impose des standards que le matériel Apple ne respecte pas sans travail. L'exemple le plus clair est la gestion de l'énergie du processeur. Asahi utilise pour cela un pilote Linux spécifique à Apple, alors que l'ARM64 principal attend que la gestion de l'énergie passe par PSCI, l'interface standard de coordination des états d'alimentation. Combler cet écart suppose d'implémenter la conformité PSCI via les services d'exécution UEFI plutôt que de proposer le pilote sur mesure en amont. La prise en charge de l'attente d'interruption profonde n'existe pour l'instant qu'en aval pour la même catégorie de raisons. C'est normal pour ce projet et ce n'est pas un signe d'ennui : les fonctions sont éprouvées en aval, puis retravaillées dans une forme que la communauté du noyau acceptera, et la seconde étape prend régulièrement plus de temps que la première.

Quelles machines M3 sont couvertes ?

Le rapport décrit un travail portant sur toute la gamme M3 plutôt que sur un modèle unique, avec des webcams fonctionnelles sur les Mac de la série M3 qui en possèdent une. Le M3 Max a demandé un petit ajustement de pilote pour que sa webcam fonctionne, bonne illustration de la manière dont les choses se passent : Apple fait varier les détails d'une puce à l'autre au sein d'une même famille, donc chaque variante demande une vérification plutôt qu'une extrapolation depuis le modèle de base. L'audio a posé un problème plus large, parce qu'Apple a changé le matériel audio pour la génération M3, ce qui a imposé une nouvelle rétroconception plutôt qu'une adaptation des pilotes M1 et M2.

Et les Mac M4 et M5 ?

Nettement plus tôt dans le processus, et le rapport est franc là dessus. Le travail sur M4 et M5 est engagé, avec l'activation du stockage NVMe et des améliorations PCIe citées comme chantiers en cours, mais la mise en route est décrite comme incomplète avec d'autres difficultés devant. Le schéma est constant sur ce projet : chaque nouvelle génération met longtemps à atteindre le point que M3 vient d'atteindre, et le GPU suit bien après le reste. Qui achète un Mac M4 ou M5 avec l'intention d'y faire tourner Linux devrait considérer cela comme un projet pour une année ultérieure, pas pour celle ci.