Dynamic Triple Buffering Hopefully Will Land For GNOME 44

[Linuxxx]

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

FWIW, the Wayland desktop of Ubuntu 22.04 LTS performs without a single hiccup on my discrete AMD Radeon R9 380 GPU.

[Linuxxx]

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?

AFAIK, there's not much the kernel devs can do about the dynamic reclocking of GPUs, because it's all handled by the locked down firmware.

[Anvil]

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.

Rust is a Pile of Poo

[clapbr]

Yeah. Good old KWIN_TRIPLE_BUFFER variable is still available.

never had good results with this hack on any AMD/NVIDIA GPU, always makes the things you try to fix worse even with Triple Buffer forced on driver also.
When vsync was shit years ago with amdgpu it didnt help at all also, and no hacks been necessary with that for a couple of years already.
Frame timings start going crazy with a couple of windows rendering at different rates.

[Quackdoc]

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

considering they gave up on the C one too, not convinced, smithay and cosmic seem to be progressing perfectly fine.

[xAlt7x]

FWIW, the Wayland desktop of Ubuntu 22.04 LTS performs without a single hiccup on my discrete AMD Radeon R9 380 GPU.

Unfortunately that's not the case for me with AMD Lucienne (Zen 2 mobile integrated GPU). Hovewer env variable MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 / MUTTER_DEBUG_FORCE_KMS_MODE=simple (as mentioned in Daniel Van Vugt blog post) helps with sluttering.

[jorgepl]

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".



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.

Very interesting insight on the iOS topic.

Precisely because iOS should have the best drivers out there, given the platform writers are also the driver writers. I wonder if iOS had triple buffering since v1 and that's why it was smoother than the competition back then.

[AnAccount]

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

Disclaimer: The actual speed was not the issue here, the original comment mentioning rust was a joke. Also, using rust would also most likely not give any performance improvements, but as I said that was not the issue in the first place. So, this is really a side track not related to the issue.

So, with the disclamer out of the way, from what I see the Way Cooler was wrapping wlroots C api, to use with rust. And then, you will get an overhead. There are tools to assist with this, like bindgen, but you will still have to work with the C api to some extent wrapping it in unsafe and do type conversion aso. It might still be worth it from a reliability point of view, but it is not without a cost. Threre are other projects like Cosmic that are implementing compositors in rust which seems to do just find, but from what I understand they do not wrap wlroots. But, remember the rust suggestion was a joke in the first place....

[kpedersen]

Disclaimer: The actual speed was not the issue here

Speed doesn't matter; I clearly stated it was the work involved in creating the bindings against C that was the issue.

But, remember the rust suggestion was a joke in the first place....

Rust suggestions are always a joke aren't they?

considering they gave up on the C one too, not convinced.

Heh, fair; but they did mention in a blog that the project was abandoned for a different reason rather than language. This is more due to the scope required in creating a Wayland compositor in general. Relating to why the Wayland ecosystem will always have very little choice of standalone compositors compared to X11 WMs.

[Quackdoc]

Threre are other projects like Cosmic that are implementing compositors in rust which seems to do just find, but from what I understand they do not wrap wlroots.

and it does do pretty well, it uses smithay, which is the wlroots equivalent, its not super featureful but its good enough for a basic desktop, I've used anvil (kinda like the weston of smithay) as well as cosmic, and so far cosmic is actually not too bad if you can discount the crashing once every 20 minutes or so, but to be completely fair, I build the git versions of all the packages linked in cosmic-epoch, so thats really not a fair comparison. however for a stacking/tiling combo compositor, so far it looks and feels really promising, fun to dink around with, but afaik they arent even at the stage were they are taking user error reports