Dynamic Triple Buffering Hopefully Will Land For GNOME 44

[eagleoneraptor]

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.

Jokes aside, is the sentence "They should just rewrite Mutter and make a new one on top of wlroots" also a joke? Because I don't really know for certain.

[agd5f]

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?

At the end of the day, it's the same solution: force the GPU to run at a higher frequency longer. Either by keeping it busy or manually forcing the clocks high longer. Arguably keeping it running slightly longer is more efficient than ramping it up and down several times.

It's not an easy problem to solve in either software or firmware. The GPU kernel driver doesn't know how big each job is or how long it will take to complete. If it always forced the clocks to ramp to high it would waste power on a lot of workloads that don't need it. Sure you could add a hint that the app could send to the kernel driver to influence it's decision, but then every app would need to be aware of every GPU to determine when it needed the hint or not if you really wanted it to work well across a wide range of GPUs.

[MihaiBojescu]

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.

While many developers like Rust for its benefits, it sadly is not a magic bullet for each and every performance problem.