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.

Canonical's Daniel van Vugt has been working on this dynamic triple buffering for GNOME's Mutter compositor due to the sluggish experience he has sometimes seen with Intel graphics in particular. Switching from double to triple buffering does lead to enough work that it generally causes the GPU performance state to increase.

With these ongoing patches, double buffering would be preserved except when presentation times are being missed.

His "v3" patches to Mutter that have come together over the past few days can be found via the triple-buffer-with-states branch. One of the patches goes on to explain the work being done and the effort to avoid added latency:

While double buffering will go from IDLE to PRESENTING_MAX, triple buffering and higher will encounter the PRESENTING state in between.

In the PRESENTING state, a new frame is allowed to be scheduled before the previous one completes presentation. But in this state we can't use `calculate_next_update_time_us` because it would give a `next_update_time_us` that's too old (a repeat), causing premature rendering and high latency. Instead we calculate the next update time as precisely one frame interval after the last. This avoids creating an increase in latency that blind triple buffering or higher would, but also allows for an implicit scaling up to triple buffering when and if it is needed (the previous frame doesn't present on time).

This way we can achieve the higher framerates of triple+ buffering without incurring higher latency (presuming the system can keep up with rendering at the advertised refresh rate).

We'll see ultimately how this work goes and if all goes well could be picked up for GNOME 3.40 next spring or we'll see if it gets warranted for back-porting to a 3.38.x point release.