GNOME's Dynamic Triple Buffering "Ready To Merge"

[phoronix]

Phoronix: GNOME's Dynamic Triple Buffering "Ready To Merge"

It looks like GNOME 46 might finally see the dynamic triple buffering support merged for Mutter to enhance the performance particularly for systems with integrated graphics...

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

[ehansin]

Nice! I don't use Gnome too much, as my default lately has been to install Fedora Workstation, which of course gets me Gnome and what they considered needed for a standard installation. Lately been using lighter desktop managers like Sway and Hyprland (and looking for more to come in that space as Wayland native!) I probably install more than I need, and have more running processes than I need, even when in say Sway due to what GDM or whatever starts these up. But not a big deal. And sometimes want to be in a more full desktop, and in that case it end up being Gnome at this point.

I also tend not to use dedicated graphics cards as not a gamer, so the iGPU tends to be fine for me. Sounds like this triple buffering really helps in this usage case. Based on things I have read here in the past, Daniel van Vugt sounds like quite the asset in this space, really put forward a lot of "low-level" improvements. There are some real rock stars out there that keep pushing things forward.

I know people complain about Wayland and other Linux stuff being half-baked, etc. But I see so many small (and some large!) improvements happening that are giving desktop Linux some legs. The recent PipeWire 1.0 release being an example, opening up greater possibilities with audio, including a unified infrastructure that brings together both consumer and pro-level audio. All good stuff in my opinion.

[bearoso]

There was an article yesterday about Kwin doing this the right way:

https://www.phoronix.com/news/KDE-KWin-DMA-Fence-Deadline

Do what Kwin did instead, because this will never be accepted into mainline. It's too hacky.

[RealNC]

There was an article yesterday about Kwin doing this the right way:

https://www.phoronix.com/news/KDE-KWin-DMA-Fence-Deadline

These two things are orthogonal to each other. So actually having both is the right approach. Just because you use a DMA fence to set a deadline won't magically make your hardware incapable of not finishing all frames fast enough.

[bearoso]

I also tend not to use dedicated graphics cards as not a gamer, so the iGPU tends to be fine for me. Sounds like this triple buffering really helps in this usage case. Based on things I have read here in the past, Daniel van Vugt sounds like quite the asset in this space, really put forward a lot of "low-level" improvements. There are some real rock stars out there that keep pushing things forward.

Daniel's value is actually understanding what's important for normal users and putting it into practice. Gnome now has more people working on the technical side of mutter, so I'm optimistic it'll get better.

[ehansin]

Daniel's value is actually understanding what's important for normal users and putting it into practice. Gnome now has more people working on the technical side of mutter, so I'm optimistic it'll get better.

That is awesome to hear. Also, reading some of the GitLab issues/merge requests (and mailing lists posts, etc.) I get the impression that there is a lot of cross-environment collaboration and discussion that sometimes get overlooked, people sometimes thinking the silos are more siloed than maybe they are.

On that note, I am a non-coder, but I do look at code some to get a sense of structure in different languages, etc. I also like to read the comments in these issues, merge requests, etc. - the back and forth that takes place looking to solve problems. And mentally I keep getting a better and better sense of how things work, at least at a good enough level for me. I got into computing as a kid back when Commodore PETs and Apple IIs started showing up in our schools (elementary school for me.) I love having access to seeing all this development happening in the open. Open source has made computing fun for me, even if I cannot contribute directly with code. It really is pretty awesome.

[s_j_newbury]

These two things are orthogonal to each other. So actually having both is the right approach. Just because you use a DMA fence to set a deadline won't magically make your hardware incapable of not finishing all frames fast enough.

Did you read the article? The idea is the GPU clocks are increased sufficiently to meet the deadline for the DMA fence. The GNOME approach is to do more work to keep the GPU busy. They are both trying to solve the same underlying issue.

[RealNC]

Did you read the article? The idea is the GPU clocks are increased sufficiently to meet the deadline for the DMA fence. The GNOME approach is to do more work to keep the GPU busy. They are both trying to solve the same underlying issue.

Triple buffering does more than that. It allows the GPU to start working on a new frame even though the previous one has not been presented yet because it's waiting for the next vblank. This avoids the situation where the frame rate is cut in half when the GPU can't keep up for whatever reason. As a result, hiccups due to missed frames look much less severe with triple buffering because FPS isn't gonna jump from 60 to 30, but instead from 60 to some arbitrary value like 54 or 58 (meaning whatever frame time those FPS values represent.)

It is really beneficial to use both approaches.

[Myownfriend]

Triple buffering does more than that. It allows the GPU to start working on a new frame even though the previous one has not been presented yet because it's waiting for the next vblank. This avoids the situation where the frame rate is cut in half when the GPU can't keep up for whatever reason. As a result, hiccups due to missed frames look much less severe with triple buffering because FPS isn't gonna jump from 60 to 30, but instead from 60 to some arbitrary value like 54 or 58 (meaning whatever frame time those FPS values represent.)

It is really beneficial to use both approaches.

Yea, I really don't get why people act like Triple Buffering is a hack or something new. It's just logistically the only way to keep the GPU busy if frame A is done being drawn and frame B is still being displayed.

[s_j_newbury]

Yea, I really don't get why people act like Triple Buffering is a hack or something new. It's just logistically the only way to keep the GPU busy if frame A is done being drawn and frame B is still being displayed.

Because it's unnecessary if the GPU can prepare the next frame during the vblank interval. Triple buffering uses more VRAM, and does result in wasted frames, higher latency and/or jitter, which is why it is dynamic in this case. The benefit of triple buffering is it doesn't have the observed downside of double buffering which is failure to meet the deadline results in half the frame rate as the frame needs to wait for the next interrupt, instead it can always flip to the latest complete buffer on each interrupt.

I would be surprised if there are many GPUs out there with accelerated drivers incapable of rendering a desktop at 60Hz at some available clock frequency. Even amongst vintage hardware, where it's capable of meeting the minimum API requirements.