KDE Plasma 6.8 will stop pushing frames through system memory when an application renders on a different GPU than the compositor, which is the single biggest cause of poor external GPU performance on Wayland. Xaver Hugl landed support for version 6 of the linux-dmabuf protocol in KWin, letting the compositor advertise a list of GPUs rather than one and letting applications pick which GPU should import a buffer. On a Framework Laptop 13 with an RX 5700 XT in an enclosure, vkcube went from 55 to 120 frames per second and Cyberpunk 2077 on low settings from 27 to 50. Hybrid laptops see smaller gains.
The short answer
KWin developer Xaver Hugl published the results of his multi GPU work on July thirty first. KWin now implements version 6 of the linux-dmabuf protocol, which lets a Wayland compositor advertise several GPUs instead of exactly one and lets clients choose which GPU imports a buffer. That removes the forced round trip through system memory when an application renders on a GPU the compositor is not running on. The gains are largest on external GPUs, where that round trip was crossing a USB-C link. The work is landing for Plasma 6.8, requires Wayland rather than X11, and needs the display attached to the primary GPU to take effect.
External GPU enclosures on Linux have always had a gap between the hardware you paid for and the frame rate you got. The card was fine. The bottleneck was that every finished frame was being carried back across the cable it had just come from.
The problem was in the protocol
Wayland compositors hand buffers around using linux-dmabuf, and until now that protocol described a single GPU. The compositor said "this is my device", and clients allocated buffers the compositor's device could import.
That is fine when there is one GPU. When a game renders on a dedicated card and the compositor runs on the integrated one, the buffer has to become readable by the second device, and the kernel achieves that by moving it through system memory. Every frame leaves video memory, crosses the bus, and comes back. On an internal card that is a tax. On an external GPU, where the bus is a USB-C connection, it is most of your performance.
Version 6 of the protocol changes the shape of the conversation. The compositor advertises a list of GPUs, and the client says which GPU should import a given buffer. Once the compositor can scan out directly from the card that rendered the frame, there is no copy to make.
The protocol diff is the small part. Hugl describes more than two years of work in KWin to get there: tracking multiple GPUs, handling hotplug when a card appears or disappears, and building a Vulkan path for the multi GPU copies that genuinely cannot be avoided, plus driver side changes so the copy can be skipped at all.
The numbers, and the machine they came from
Hugl tested on a Framework Laptop 13 with an RX 5700 XT in an external enclosure, driving a 5120x1440 monitor at 120 Hz.
vkcube went from 55 frames per second to 120, which is the display's full refresh rate, so the ceiling is now the monitor rather than the link. Cyberpunk 2077 on the low preset went from 27 to 50, which Hugl puts at more than 80% better.
The caveat is in the setup, not the code. Those are external GPU numbers, where the copy was crossing a USB-C link. On a laptop whose dedicated GPU is soldered next to the integrated one, the copy was never the main cost, and Hugl expects something in the range of 5 to 10%.
Read the conditions before you expect it
Three limits decide whether any of this reaches you.
Compositing still happens on the primary GPU. The gain comes from direct scanout, so the display has to be attached to that GPU for the buffer to go straight to the screen. If your monitor is wired to the other card, the path the optimisation removes is still in play.
Anything that forces the compositor to touch the buffer blocks it. On hardware without colour pipeline support, which includes Hugl's own test GPU, that means HDR, night light and colour profiles have to be off to get the fast path.
And it is Wayland only. Hugl is direct about why: implementing the protocol usefully in Xwayland is extremely difficult because of assumptions X11 makes about how buffers work. X11 applications do not benefit.
You also need the other half of the stack. The driver has to know it can skip the copy, and that support is arriving in Mesa and in the NVIDIA driver in parallel with the KWin side.
What comes next
This is labelled part one. Hugl says he already has a merge request open to lift the restriction that compositing must happen on the primary GPU, which is the constraint that currently decides who benefits. Removing it would turn this from a fix for people whose display happens to be wired to the right card into a fix for anyone running two GPUs.
For now, if you have an external GPU and a Wayland session, Plasma 6.8 is the release to watch. If you have a hybrid laptop, expect a few percent and be pleasantly surprised if you get more.
Sources and further reading
- Xaver Hugl: fixing multi GPU performance, part 1
- Phoronix: KDE Plasma 6.8 to enjoy huge performance gains for multi GPU and eGPU
- The KDE Plasma desktop
- Wayland protocols, including linux-dmabuf
Frequently asked questions
What was actually wrong with multi GPU before this?
The linux-dmabuf protocol only let a compositor advertise a single GPU. When a game rendered on a dedicated or external card while the compositor ran on the integrated one, the buffer had to become something the compositor's GPU could read, and the kernel resolved that by moving it through system memory. So every frame made a round trip out of video memory and back. On an internal dedicated GPU that costs you something. On an external GPU behind a USB-C link it is close to catastrophic, because the frame is crossing a connection with a fraction of the bandwidth.
What does version 6 of the protocol change?
It lets the compositor advertise a list of GPUs instead of one, and it lets an application say which GPU should import a given buffer. That is enough to make the copy avoidable: if the compositor can scan a buffer out directly from the GPU that produced it, nothing has to be moved at all. The protocol change is small, but the work behind it was not. Hugl describes more than two years of KWin infrastructure, including GPU tracking, hotplug handling and a new Vulkan path for the multi GPU copies that still do have to happen.
How much faster is it really?
It depends entirely on your setup, and the honest summary is that external GPUs get a lot and internal hybrid laptops get a little. On Hugl's test machine, a Framework Laptop 13 with an RX 5700 XT in an enclosure driving a 5120x1440 display at 120 Hz, vkcube went from 55 to 120 frames per second, which is the monitor's full refresh rate, and Cyberpunk 2077 at the low preset went from 27 to 50, more than 80% better. A typical hybrid laptop with an internal dedicated GPU is closer to 5 to 10%, because the link between the two GPUs is not the bottleneck there.
What are the conditions for getting the gain?
Three, and they matter. Compositing still happens on the primary GPU, so the benefit comes from direct scanout, which means the display needs to be attached to that GPU. The optimisation is blocked when the compositor cannot hand the buffer to the display untouched, so on hardware without colour pipeline support that means HDR, night light and colour profiles have to be off. And it is Wayland only. Hugl is explicit that implementing this usefully in Xwayland is very hard because of assumptions X11 makes, so X11 applications do not get it.
Is this the end of the work?
No. Hugl calls this part one and says he already has a merge request to lift the restriction that compositing must happen on the primary GPU, with a part two to follow. That restriction is the one that decides how many setups actually benefit today, so lifting it is the difference between a fix for people with a display wired to the right card and a fix for everyone with two GPUs. You also need the other half of the stack: the driver has to know how to skip the copy, and support for that is landing in Mesa and the NVIDIA driver alongside the KWin side.