Dynamic Triple Buffering Hopefully Will Land For GNOME 44

[MastaG]

They should just rewrite the core components like Mutter in rust.
Then it would be fast enough by itself without the need for a triple buffer.

[jorgepl]

They should just rewrite the core components like Mutter in rust.
Then it would be fast enough by itself without the need for a triple buffer.

You must be joking, right?

[smitty3268]

Can someone again explain why this is the proper way to fix this issue, rather than fixing the underlying GPU driver issues causing it to not ramp up clocks fast enough?

Even just adding some kind of desktop mode or sensitive hint in order to force the driver to ramp clocks more quickly than their current algorithm seems like it'd be less of a hack.

Or have the desktop devs just given up on the kernel devs ever fixing the drivers?

[kpedersen]

They should just rewrite the core components like Mutter in rust.

This is a good hands on article on why Rust is a pain in the arse for this kind of task and why people like to talk about Rust more than actually using it.

Giving up on wlroots-rs (way-cooler.org)

It all boils down to bindings against underlying C. Bindgen and swig are only viable solutions for people who haven't actually tried using them

[mirmirmir]

Can someone again explain why this is the proper way to fix this issue, rather than fixing the underlying GPU driver issues causing it to not ramp up clocks fast enough?

Even just adding some kind of desktop mode or sensitive hint in order to force the driver to ramp clocks more quickly than their current algorithm seems like it'd be less of a hack.

Or have the desktop devs just given up on the kernel devs ever fixing the drivers?

That raises a question. Does this patch only affect Intel gpu? Can anyone confirm any benefits on non-Intel devices?

[MastaG]

You must be joking, right?

I am indeed.
Having no experience with rust at all, I just like to make the "Rust beats everything"-quote every now and then.

[sarmad]

They should just rewrite the core components like Mutter in rust.
Then it would be fast enough by itself without the need for a triple buffer.

You forgot to add /s

[sarmad]

Any Mutter dev hear to comment on how mutter internally does the rendering? I remember some time ago doing a simple test and realizing that Mutter seems to be copying all the windows regardless of whether they are hidden by other windows, i.e just copying all windows to the display buffer back to front without doing any clipping to save unneeded pixel copies. I tried doing the test again on Ubuntu 22.04 but don't clearly see the same issue and I'm not sure whether that's just a side effect of this triple buffering.

The test I did was simple: put a lot of windows all in full screen mode, then film the screen with a fast camera (slow mo video) while doing the activities animation. What I noticed at the time was that the animation starts choppy and as the windows get smaller the animation becomes less choppy and eventually becomes smooth. The reverse also happens. I.e. in the activities close animation the animation starts smooth and becomes choppy as the windows become bigger even though they start covering each other. If clipping was done then the amount of pixels copied would remain roughly the size of the frame buffer and hence performance shouldn't degrade as the windows become bigger.

[treba]

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.

Short reminder that the key gnome dev in question is one of the main "doers" and just asks for things to be done properly so they don't get in the way. Similar to how kernel devs don't take in every patch that is carried downstream somewhere "because it works".

Any Mutter dev hear to comment on how mutter internally does the rendering? I remember some time ago doing a simple test and realizing that Mutter seems to be copying all the windows regardless of whether they are hidden by other windows, i.e just copying all windows to the display buffer back to front without doing any clipping to save unneeded pixel copies. I tried doing the test again on Ubuntu 22.04 but don't clearly see the same issue and I'm not sure whether that's just a side effect of this triple buffering.

The test I did was simple: put a lot of windows all in full screen mode, then film the screen with a fast camera (slow mo video) while doing the activities animation. What I noticed at the time was that the animation starts choppy and as the windows get smaller the animation becomes less choppy and eventually becomes smooth. The reverse also happens. I.e. in the activities close animation the animation starts smooth and becomes choppy as the windows become bigger even though they start covering each other. If clipping was done then the amount of pixels copied would remain roughly the size of the frame buffer and hence performance shouldn't degrade as the windows become bigger.

What you're describing is correct for animations - so called "culling" is not done in that case (but is done during "normal" usage). There's a WIP branch fixing that though: https://gitlab.gnome.org/GNOME/mutte..._requests/1497

That's however in most cases not the reason why the animation like the one to the overview is not smooth. The problem there is actually how most drivers decide when to ramp up the clocks, as apparently most other platforms, including e.g. iOS or Android, are using triple-buffering in a similar way as proposed by Daniel.

[xAlt7x]

Does KDE have such a thing?

Yeah. Good old KWIN_TRIPLE_BUFFER variable is still available.