A MacBookPro15,1 running Linux idles at about twenty four watts, and roughly twelve of those go to a discrete GPU that is doing nothing. You could already avoid that by booting on the integrated GPU, except that once GMUX powered the discrete card down, nothing could bring it back, so you traded away hybrid graphics and working suspend to get your battery life. A three patch series posted to the kernel mailing list on Wednesday, August 12, closes that gap across apple-gmux, amdgpu and the HDA audio controller. After three weeks of testing on both the 2018 and 2019 revisions, the discrete GPU now powers down and comes back.
The short answer
The 2018 and 2019 MacBook Pro 15,1 hands Linux the discrete GPU as primary, and idles at around twenty four watts with about twelve of them going to a card that may be doing nothing. Booting on the integrated GPU avoided that but broke everything else, because once GMUX powered the discrete card down the kernel could not bring it back. A three patch series posted on August 12 supplies the missing power lifecycle across apple-gmux, amdgpu and the HDA controller, so the discrete GPU moves between DynOff and DynPwr, DRI_PRIME offloading works and external monitors work.
Twelve watts is not an abstract number on a laptop. It is roughly the difference between a machine you can take to a meeting without its charger and one you cannot.
That is what a MacBookPro15,1 has been paying to Linux for years, and a three patch series posted on Wednesday finally addresses it.
The trap in the middle
The MacBookPro15,1, which is the 2018 and 2019 fifteen inch MacBook Pro, normally starts Linux with the discrete GPU as primary. On the machines the patch authors tested, that produces about twenty four watts of idle draw, of which around twelve is attributable to a discrete GPU that may be doing nothing whatsoever.
You could already dodge that by telling the machine to boot on the integrated GPU. GMUX powers the discrete card down and your idle draw halves.
Then you are stuck. The kernel had no way to bring the discrete GPU back up after GMUX had powered it off. So the choice was not really between two configurations, it was between a laptop that burns twelve watts doing nothing and a laptop with no discrete GPU at all and no working suspend. Neither of those is hybrid graphics. Hybrid graphics is the card being asleep until you need it.
What the series actually adds
Andre Eikmeyer posted the three patches, with Atharva Tiwari as the author of the apple-gmux work, and the description of what was missing is precise: the power lifecycle.
Powering a GPU down is the easy half. Bringing it back is where the work lives, because the card has to re-enumerate on the PCI bus, restore its state, and do so without any other part of the system having made assumptions while it was gone.
That last point is why an audio driver is in a graphics patch series. A discrete GPU on the PCI bus also presents an HDA audio controller, the one that carries sound over HDMI and DisplayPort, and the two functions share a power state. Get that wrong in one direction and the audio side holds a reference that stops the card ever reaching low power, so you save nothing. Get it wrong in the other and the graphics driver powers down a device the audio side still thinks it can talk to, which hangs.
So the series spans three subsystems: platform/x86 for apple-gmux, the amdgpu driver, and ALSA. All three have to agree.
With the patches applied and the integrated GPU as primary, the discrete GPU transitions between DynPwr and DynOff as demand requires. Offloading through DRI_PRIME works, so a game or a compute job can run on the discrete card while the desktop stays on the integrated one. External monitor support works too, which is not a footnote given that on many laptops the external display outputs are physically wired to the discrete GPU.
The testing is the convincing part
Most patch series arrive with a note that the author tested it on their machine. This one arrived with three weeks of use across both the 2018 and 2019 revisions of the MacBookPro15,1, covering runtime suspend and resume, system suspend and resume, repeated GPU wakeups, and a variety of Thunderbolt and USB-C external monitors.
Read that list again and notice what it is. Those are precisely the operations that break when a power lifecycle is subtly wrong. Repeated wakeups catch state that is restored once but not twice. System suspend catches ordering problems between subsystems. External monitors catch the case where the card comes back but its display engine does not. The authors were not demonstrating that it works, they were demonstrating they went looking for the specific ways it fails.
Eikmeyer's summary is that it is a large step forward in usability, convenience and battery life for everyone who tested it. On a machine where the alternative was twelve watts of nothing, that reads as fair rather than promotional.
What this means in practice
Not yet, is the honest answer on timing. The patches went out for review on August 12 and have not been merged. Code touching three subsystems needs agreement from three sets of maintainers, and that is rarely quick.
What is worth noting is the shape of the story rather than the schedule. These are nearly eight year old laptops, they were never designed with Linux in mind, and someone spent three weeks testing suspend cycles to reclaim twelve watts for the people still running them. That is the same pattern we saw when the Dell Latitude 7320 finally got its Linux webcam after five years: hardware enablement work rarely arrives on the schedule the hardware vendor would have chosen.
If you have one of these machines and you have been running it on the integrated GPU with no way back, this is the series to watch. If you have been running it on the discrete GPU because you needed it occasionally, you have been paying twelve watts for that convenience, and there is an end in sight.
Sources and further reading
- Linux finally seeing patches for better hybrid graphics on 2018 to 2019 era MacBook Pros, Phoronix, August 12, 2026
- PATCH 1/3 platform/x86, apple-gmux, add MacBookPro15,1 dGPU power sequence, dri-devel, August 12, 2026
- apple-gmux driver documentation, Linux kernel
- PRIME render offload, freedesktop documentation
Frequently asked questions
What is GMUX and what does it have to do with power draw?
GMUX is the Apple hardware multiplexer that sits between the two GPUs in a dual graphics MacBook Pro and the display. It decides which GPU drives the panel and it controls power to the discrete card. On the MacBookPro15,1 the machine normally hands Linux the discrete GPU as primary, and that costs about twelve watts at idle for a card that may be doing nothing at all, out of roughly twenty four watts total. Selecting the integrated GPU at boot avoids the cost. The problem being fixed is what happens next: once GMUX has powered the discrete GPU down, the kernel had no way to bring it back, so the machine was stuck with the integrated GPU and no working suspend rather than genuinely switching between them.
What do DynOff and DynPwr mean in this context?
They are the two runtime power states the discrete GPU moves between under this series. DynPwr is the powered and usable state, DynOff is powered down. A working hybrid graphics setup needs both transitions to be reliable in both directions, not just the way down. That is the whole difficulty here: powering a GPU off is easy, and getting it to come back cleanly, re-enumerate on the PCI bus, restore its state and cooperate with the audio device that shares its function is where the work is. With the series applied the card transitions between DynOff and DynPwr as demand requires, which is what makes offloading practical rather than theoretical.
Why does an audio controller appear in a graphics patch series?
Because a discrete GPU is not just a graphics device on the PCI bus. It also presents an HDA audio controller, the one that carries sound out over HDMI and DisplayPort, and the two functions share the device's power state. If the graphics driver powers the card down while the audio side still believes it is present and usable, or if the audio side keeps a reference that stops the card ever reaching a low power state, the result is either a hang or a device that never actually saves you any watts. This is why the series spans three subsystems: platform/x86 for apple-gmux, the amdgpu driver, and ALSA. Any one of them getting the lifecycle wrong breaks the whole thing.
What is DRI_PRIME and how does it fit in?
DRI_PRIME is the environment variable that tells a program to render on the secondary GPU rather than the primary one. Set it and a game or a compute workload runs on the discrete card while the desktop keeps using the integrated GPU, with the finished frames handed back for display. That is the arrangement this series makes possible: integrated GPU as primary so the machine idles cheaply, discrete GPU asleep until something explicitly asks for it. Without a working power lifecycle the discrete card would have to stay awake to be available, which defeats the point. External monitor support works in the same configuration, which matters because on many laptops the external outputs are wired to the discrete GPU.
When can we actually use this, and how well was it tested?
Not yet, and better than most patch series arrive. This was posted for review on the kernel mailing list on August 12, so it has not been merged, and code touching three subsystems generally needs sign off from all three before it lands. The testing story is unusually strong for a first posting: three weeks of use on both the 2018 and 2019 MacBookPro15,1 revisions, covering runtime suspend and resume, system suspend and resume, repeated GPU wakeups, and a range of Thunderbolt and USB-C external monitors. That is the list of things that break when a power lifecycle is subtly wrong, which suggests the authors knew exactly which failures to hunt for.