Un MacBookPro15,1 sous Linux consomme environ vingt-quatre watts au repos, et près de douze d'entre eux vont à un GPU dédié qui ne fait rien. On pouvait déjà éviter cela en démarrant sur le GPU intégré, sauf qu'une fois le GPU dédié éteint par GMUX, plus rien ne pouvait le rallumer : vous échangiez donc le double GPU et la mise en veille fonctionnelle contre votre autonomie. Une série de trois correctifs publiée sur la liste du noyau le mercredi 12 août comble ce manque à travers apple-gmux, amdgpu et le contrôleur audio HDA. Après trois semaines d'essais sur les révisions 2018 et 2019, le GPU dédié s'éteint et revient.
The short answer
Les MacBook Pro 15,1 de 2018 et 2019 confient à Linux le GPU dédié comme carte principale, et consomment environ vingt-quatre watts au repos, dont une douzaine pour une carte qui peut ne rien faire. Démarrer sur le GPU intégré évitait cela mais cassait tout le reste, car une fois la carte dédiée éteinte par GMUX, le noyau ne savait pas la rallumer. Une série de trois correctifs publiée le 12 août fournit le cycle de vie d'alimentation manquant à travers apple-gmux, amdgpu et le contrôleur HDA : le GPU dédié passe de DynOff à DynPwr, le déport DRI_PRIME fonctionne et les écrans externes aussi.
Douze watts, sur un portable, ce n'est pas un chiffre abstrait. C'est à peu près la différence entre une machine que vous emportez en réunion sans son chargeur et une machine que vous n'emportez pas.
C'est ce qu'un MacBookPro15,1 paie à Linux depuis des années, et une série de trois correctifs publiée mercredi s'y attaque enfin.
Le piège du milieu
Le MacBookPro15,1, c'est-à-dire le MacBook Pro quinze pouces de 2018 et 2019, démarre normalement Linux avec le GPU dédié comme carte principale. Sur les machines testées par les auteurs des correctifs, cela produit environ vingt-quatre watts de consommation au repos, dont une douzaine imputables à un GPU dédié qui peut ne strictement rien faire.
On pouvait déjà esquiver cela en demandant à la machine de démarrer sur le GPU intégré. GMUX éteint la carte dédiée et votre consommation au repos est divisée par deux.
Et là, vous êtes coincé. Le noyau n'avait aucun moyen de rallumer le GPU dédié une fois que GMUX l'avait éteint. Le choix ne se faisait donc pas vraiment entre deux configurations, mais entre un portable qui brûle douze watts à ne rien faire et un portable sans aucun GPU dédié et sans mise en veille fonctionnelle. Ni l'un ni l'autre n'est du double GPU. Le double GPU, c'est la carte endormie jusqu'à ce que vous en ayez besoin.
Ce que la série apporte réellement
Andre Eikmeyer a publié les trois correctifs, avec Atharva Tiwari comme auteur du travail sur apple-gmux, et la description de ce qui manquait est précise : le cycle de vie d'alimentation.
Éteindre un GPU, c'est la moitié facile. C'est le rallumer qui demande du travail, parce que la carte doit se réénumérer sur le bus PCI, restaurer son état, et le faire sans qu'aucune autre partie du système n'ait pris de raccourci pendant son absence.
Ce dernier point explique la présence d'un pilote audio dans une série graphique. Un GPU dédié sur le bus PCI présente aussi un contrôleur audio HDA, celui qui transporte le son par HDMI et DisplayPort, et les deux fonctions partagent un état d'alimentation. Trompez-vous dans un sens et la partie audio garde une référence qui empêche la carte d'atteindre la basse consommation : vous n'économisez rien. Trompez-vous dans l'autre et le pilote graphique éteint un périphérique que la partie audio croit encore joignable : cela bloque.
La série couvre donc trois sous-systèmes : platform/x86 pour apple-gmux, le pilote amdgpu, et ALSA. Les trois doivent s'accorder.
Avec les correctifs appliqués et le GPU intégré comme carte principale, le GPU dédié passe de DynPwr à DynOff selon la demande. Le déport via DRI_PRIME fonctionne, si bien qu'un jeu ou un calcul peut tourner sur la carte dédiée pendant que le bureau reste sur la carte intégrée. La prise en charge des écrans externes fonctionne aussi, ce qui n'est pas une note de bas de page quand on sait que sur beaucoup de portables les sorties d'affichage externes sont physiquement câblées au GPU dédié.
Ce sont les essais qui convainquent
La plupart des séries de correctifs arrivent avec une note disant que l'auteur a testé sur sa machine. Celle-ci arrive avec trois semaines d'usage sur les deux révisions 2018 et 2019 du MacBookPro15,1, couvrant la mise en veille et la reprise à l'exécution, la mise en veille et la reprise du système, des réveils GPU répétés, et un éventail d'écrans externes Thunderbolt et USB-C.
Relisez cette liste et voyez ce qu'elle est. Ce sont exactement les opérations qui cassent quand un cycle de vie d'alimentation est subtilement faux. Les réveils répétés attrapent l'état restauré une fois mais pas deux. La mise en veille système attrape les problèmes d'ordonnancement entre sous-systèmes. Les écrans externes attrapent le cas où la carte revient mais pas son moteur d'affichage. Les auteurs ne démontraient pas que cela marche, ils démontraient qu'ils sont allés chercher les façons précises dont cela échoue.
Le résumé d'Eikmeyer, c'est un grand pas en avant en confort d'usage et en autonomie pour tous ceux qui ont testé. Sur une machine où l'alternative était douze watts pour rien, cela se lit comme une appréciation juste plutôt que comme une réclame.
Ce que cela change en pratique
Pas encore, voilà la réponse honnête sur le calendrier. Les correctifs sont partis en relecture le 12 août et ne sont pas fusionnés. Du code qui touche trois sous-systèmes exige l'accord de trois groupes de mainteneurs, et c'est rarement rapide.
Ce qui mérite d'être noté, c'est la forme de l'histoire plus que son calendrier. Ce sont des portables de bientôt huit ans, jamais conçus en pensant à Linux, et quelqu'un a passé trois semaines à tester des cycles de veille pour récupérer douze watts au bénéfice de ceux qui les font encore tourner. C'est le même motif que lorsque le Dell Latitude 7320 a enfin obtenu sa webcam sous Linux après cinq ans : le travail d'activation matérielle arrive rarement au calendrier qu'aurait choisi le fabricant.
Si vous possédez une de ces machines et que vous la faites tourner sur le GPU intégré sans retour possible, voilà la série à surveiller. Si vous la faites tourner sur le GPU dédié parce que vous en avez besoin de temps en temps, vous payez douze watts pour ce confort, et la fin est en vue.
Sources et pour aller plus loin
- Linux finally seeing patches for better hybrid graphics on 2018 to 2019 era MacBook Pros, Phoronix, 12 août 2026
- PATCH 1/3 platform/x86, apple-gmux, add MacBookPro15,1 dGPU power sequence, dri-devel, 12 août 2026
- Documentation du pilote apple-gmux, noyau Linux
- PRIME render offload, documentation freedesktop
Questions fréquentes
Qu'est-ce que GMUX et quel rapport avec la consommation ?
GMUX est le multiplexeur matériel d'Apple placé entre les deux GPU d'un MacBook Pro à double carte et l'écran. Il décide quel GPU pilote la dalle et il contrôle l'alimentation de la carte dédiée. Sur le MacBookPro15,1, la machine confie normalement à Linux le GPU dédié comme carte principale, ce qui coûte environ douze watts au repos pour une carte qui peut ne rien faire du tout, sur un total d'environ vingt-quatre watts. Choisir le GPU intégré au démarrage évite ce coût. Le problème corrigé, c'est la suite : une fois le GPU dédié éteint par GMUX, le noyau n'avait aucun moyen de le rallumer, si bien que la machine restait coincée avec le GPU intégré et sans mise en veille fonctionnelle, au lieu de basculer réellement entre les deux.
Que signifient DynOff et DynPwr ici ?
Ce sont les deux états d'alimentation d'exécution entre lesquels le GPU dédié se déplace grâce à cette série. DynPwr est l'état alimenté et utilisable, DynOff l'état éteint. Un double GPU qui fonctionne exige que les deux transitions soient fiables dans les deux sens, pas seulement dans le sens de l'extinction. Toute la difficulté est là : éteindre un GPU est facile, et c'est le faire revenir proprement, se réénumérer sur le bus PCI, restaurer son état et coopérer avec le périphérique audio qui partage sa fonction, qui demande du travail. Avec la série appliquée, la carte passe de DynOff à DynPwr selon la demande, ce qui rend le déport de calcul praticable plutôt que théorique.
Pourquoi un contrôleur audio apparaît-il dans une série de correctifs graphiques ?
Parce qu'un GPU dédié n'est pas seulement un périphérique graphique sur le bus PCI. Il présente aussi un contrôleur audio HDA, celui qui transporte le son par HDMI et DisplayPort, et les deux fonctions partagent l'état d'alimentation du périphérique. Si le pilote graphique éteint la carte alors que la partie audio la croit toujours présente et utilisable, ou si la partie audio conserve une référence qui empêche la carte d'atteindre un état de basse consommation, le résultat est soit un blocage, soit un périphérique qui ne vous fait économiser aucun watt. Voilà pourquoi la série couvre trois sous-systèmes : platform/x86 pour apple-gmux, le pilote amdgpu, et ALSA. Il suffit qu'un seul se trompe sur le cycle de vie pour que l'ensemble casse.
Qu'est-ce que DRI_PRIME et comment s'inscrit-il là-dedans ?
DRI_PRIME est la variable d'environnement qui indique à un programme de calculer son rendu sur le GPU secondaire plutôt que sur le principal. Positionnez-la et un jeu ou une charge de calcul tourne sur la carte dédiée pendant que le bureau continue d'utiliser le GPU intégré, les images finies étant rendues pour l'affichage. C'est exactement l'arrangement que cette série rend possible : GPU intégré comme carte principale pour que la machine consomme peu au repos, GPU dédié endormi jusqu'à ce que quelque chose le réclame explicitement. Sans cycle de vie d'alimentation fonctionnel, la carte dédiée devrait rester éveillée pour être disponible, ce qui ruine l'intérêt. La prise en charge des écrans externes fonctionne dans la même configuration, ce qui compte parce que sur beaucoup de portables les sorties externes sont câblées au GPU dédié.
Quand pourra-t-on s'en servir, et à quel point a-ce été testé ?
Pas encore, et mieux que la plupart des séries de correctifs. Le tout a été publié pour relecture sur la liste du noyau le 12 août, donc rien n'est fusionné, et du code touchant trois sous-systèmes exige en général l'accord des trois avant d'entrer. Le volet essais est inhabituellement solide pour une première publication : trois semaines d'usage sur les deux révisions 2018 et 2019 du MacBookPro15,1, couvrant la mise en veille et la reprise à l'exécution, la mise en veille et la reprise du système, des réveils GPU répétés, et un éventail d'écrans externes Thunderbolt et USB-C. C'est précisément la liste de ce qui casse quand un cycle de vie d'alimentation est subtilement faux, ce qui laisse penser que les auteurs savaient quelles pannes chercher.