Dynamic Triple Buffering Hopefully Will Land For GNOME 44

[phoronix]

Phoronix: Dynamic Triple Buffering Hopefully Will Land For GNOME 44

For over two years Canonical has been working on dynamic triple buffering for the GNOME desktop with the Mutter compositor. This triple-buffering-when-needed can dramatically boost the desktop performance especially in cases like Intel integrated graphics and Raspberry Pi boards. The triple buffering work hasn't been upstreamed yet but the hope is that it may finally be ready for upstream inclusion with GNOME 44...

https://www.phoronix.com/news/GNOME-44-Hopes-Triple-Buffering

[kpedersen]

in order to improve the desktop experience when needing to force the GPU to ramp up its performance state to get ahead in the rendering speed.

I do similar for my CPU to ramp up its performance state and get ahead in processing speed. I wrote the code myself:

while(1)
{
  // Keep busy
}

[jorgepl]

Why hasn't this been accepted in upstream yet? Is there any particular reason?

[royce]

Why hasn't this been accepted in upstream yet? Is there any particular reason?

The changes have been in Ubuntu for at least a year, and it being the most used desktop distribution I would imagine any real issues have long been found and ironed out. As far as the MR discussion goes the holdup is a key gnome dev that simply doesn't like the approach. Stark contrast between doers and chin-strokers.

[blacknova]

I hope they'd finally fix their input layout switcher under X11, since GNOME 42 it become impossible to switch layout in Intelliji IDEA. And annoying and unswitchable layout switch popup have been making my day "brighter" for even longer. I'm no fun of KDE but have been more less forced to switch to it.

[mirmirmir]

Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...

[lumks]

As far as the MR discussion goes the holdup is a key gnome dev that simply doesn't like the approach

As far as I know the main blocker is simply a lack of time. As this is no simple stand-alone MR, but depends on other MRs before it can be merged:

• onscreen/native: Only hold on to the buffers that will scan out
• KMS: Unify buffer management for all plane types

I can't see that there is anyone who don't likes it in a way that there is no chance to merge it. I see that there still is ongoing work and thats a good thing. We want quality where GNOME is happy with the results. keep in mind that GNOME are the ones who will maintain this if Ubuntu pulls the plug and leaves. (Not that this will happen, but in case) TBH I don't see this land in 44.

[lumks]

Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...

My problem with this path is that I notice it in worse battery performance. But since I keep my laptop all the time in energy saving mode, where this patch wont do anything, thats OK.

[jorgepl]

Honestly, I was fan of this patch, but then, i don't feel any gain in performance with this patch on my pre-ryzen laptop. But yeah, perf optimizations are welcome I guess...

This is not a performane optimization per se, it just ramps up the frequency of the GPU.

[Danny3]

Does KDE have such a thing?
It eels pretty slow on Wayland and I was wondering if such a thing could help its performance too.