Dynamic Triple Buffering For GNOME Still Being Worked On To Ramp Up The GPU When Needed

[phoronix]

Phoronix: Dynamic Triple Buffering For GNOME Still Being Worked On To Ramp Up The GPU When Needed

Proposed earlier this summer for GNOME's Mutter was the idea of triple buffering the desktop when the GPU is running behind in order to ideally cause that extra load to ramp up the GPU clock frequencies in order to in turn get back on track with rendering the desktop on-time. A third version of that work is now brewing albeit too late to see with the imminent GNOME 3.38.0 release...

http://www.phoronix.com/scan.php?page=news_item&px=Mutter-Triple-Buf-V3

[eydee]

Why just not stop turning Gnome into Crysis?

[You-]

Have the other developers agreed with this approach?

From the earlier merge request there were comments that suggested this was a hack working around (intel OSS) driver bugs (because if frames are being missed the driver should already be ramping up to a higher performance mode).

The developer has not even opened a merge request for this, so its premature writing an article on it. He is testing stuff and experimenting. A better time to comment would be once the merge request is ready, otherwise you get toxic comments against the developer for doing what he should be doing - trying different approaches and experimenting.

[Britoid]

This is unlikely to ever get approved (or anything like it) given that it relies on tricking the GPU driver to ramp up the clock.

[libcg_]

The v2 MR is now closed. This comes on top of the other 60+ experimental MRs he already closed.

This is called iterating, when instead of trying to figure out everything in advance, you start with something minimal, get early feedback, fix things, repeat. It works.

This is unlikely to ever get approved (or anything like it) given that it relies on tricking the GPU driver to ramp up the clock.

Wrong. The problem with double buffering is that when the vsync interval is missed, the GPU will stay idle for the next interval, which generates a negative feedback loop by forcing the driver to ramp frequency _down_ and increasing the chances of missing the vsync interval after that. Triple buffering batches things up as the driver would expect, which reduces idle time and allows the driver to ramp up frequency. It's absolutely misinformed to call it a "trick".

[Ipkh]

Wrong. The problem with double buffering is that when the vsync interval is missed, the GPU will stay idle for the next interval, which generates a negative feedback loop by forcing the driver to ramp frequency _down_ and increasing the chances of missing the vsync interval after that.

That makes almost no sense at all. Logically if the remder pipeline misses the gsync interval the hardware is/was still rendering the frame. The original buffer get sent until it gets replaced. Triple buffering adds more workload on the rendering pipeline in high COU and GPU and Memory for the extra frame. Not to mention an extra frame of latency.
This is not helpful for battery or system responsiveness and should not get merged.
The fix is to find why the frame got missed. Desktop should not be changing much and an idle desktop should be repeating tons of frames. Missing a specific refresh interval shouldn't matter that much. Tightening up the UI code would because better use of resources.

[indepe]

Gnome is not like a game that simulates events in time. As I understand it, if work piles up, triple buffering works around the gap of inactivity that would occur when the first buffer is displayed, the second buffer has been made ready to be displayed, but the first buffer isn't released yet for the following frame. Then the third buffer can be used to continue work while the first one is still on screen (and the second one already completed).

If he found a way to do this without reducing latency when there is no piling up of work, then it is a great feature and not (or not just) a driver-specific trick.

I'm saying that without having close knowledge of this, but the advantages and disadvantages of user level options for video game configuration should not be confused with the advantages and disadvantages of low level implementation possibilities (which are able to change or mitigate any user level effects known in common video games).

[libcg_]

If he found a way to do this without reducing latency when there is no piling up of work, then it is a great feature and not (or not just) a driver-specific trick.

Yes, the proposed MR falls back to double buffering to lower latency in the common case. Android does that since Jelly Bean.

[Ipkh]

That's not how modern GPUs work.
Double buffering is what you want. 1 Buffer for the current frame being displayed and 1 for the rendering frame. They simply swap once a frame is done rendering. If the frame doesn't change the GPU just outputs the current frame buffer. Since the GPU just refuses the buffer until it is swapped, a lot of power is saved. Triple buffering was a method to eliminate tearing in older GPU architectures that couldn't reuse the buffer in hardware. The problem with triple buffer is that you need to render that extra intermediary frame even when there are no changes. This is what causes the extra power and memory usage.

Realistically reducing the rendering pipeline is the best solution to see screen input faster. Otherwise you're just ramping the GPU unnecessarily.

Back then, the buffer being rendered would replace the current buffer even if it wasn't done yet. This is what causes tearing. Triple buffering works around that by always working 1 frame behind so that the back buffer was always a completed frame. Modern systems don't do this and just repeat the current frame when Vsync is in play.

[indepe]

Modern systems don't do this and just repeat the current frame when Vsync is in play.

When work has piled up, there is no question of repeating a frame. It is the opposite problem, and none of tearing only. It doesn't occur in games in the same way because for a fps game, piled up work is outdated and not of any interest anymore.

I agree with you that there is a question of why that much work piles up in the first place, for a desktop. It probably also has to do with the general structure of Gnome's rendering, which might connect more work to each buffer than necessary, but that I wouldn't know. If so, it would probably be much more difficult to change (if even practically possible).

EDIT: You seem to also imply that rendering should simply wait with swapping until the frame is completely done. But that would increase latency for those parts that are ready to be displayed (perhaps the contents of a window with high frame rate). That's what you might do within an application, but this might involve coordinating the output from multiple applications.