Mesa Adds "Block On Depleted Buffers" Option To Reduce Latency

After the idea has been discussed for about a year, Mesa 22.3 has landed a new performance option called "block_on_depleted_buffers" to wait on buffers at the end of a swap to reduce latency -- a possible one frame advantage.

When the new "block on depleted buffers" option is enabled, the client is blocked until a new buffer is available. This stalls the client's execution until a new buffer is available and at that point the client proceeds with drawing. By blocking at the end of the swap rather than the default behavior of blocking on the buffer becoming available, the frame being presented is slightly newer with a possible one frame latency reduction.

Open-source developer Roman Gilg worked on this patch based on one started by Michel Danzer who in turn started on it after Valve's Pierre-Loup A. Griffais "Plagman" opened a Mesa ticket a year ago about ensuring the next buffer at the end of SwapBuffers() for reducing the perceived latency. The notable Linux-focused Valve engineer summarized the situation as:

The common pattern followed by typical naive client apps (which is true for most games) is "sample time, simulate, draw, present, repeat". In GPU-bound scenarios, the swapchain length is the primary way that an app ends up blocking to not get too ahead of the GPU. If instead of the above, the next framebuffer was validated immediately at the end of SwapBuffers(), before returning to the client app, there would be one less frame worth of latency visible to the user in the above scenario. It would also match what other drivers and graphics stacks do.

The block_on_depleted_buffers option isn't enabled by default since it could yield missed frames if the client is taking too long for producing a new frame. Valve has already been making use of this option/patch on SteamOS and the Steam Deck for helping to reduce the perceived latency.

Roman Gilg showing off the GPUVis visualization difference for this patch with block_on_depleted_buffers enabled.

More details on this option via this merge request opened eight months ago by Roman Gilg and now merged as of yesterday for Mesa 22.3. The change affects Mesa's common DRI3 code and thus isn't limited to any particular Mesa hardware driver.

Mesa 22.3 with this option should be out as stable around late November or December depending upon how the release cycle plays off once beginning the feature freeze / release candidate phase in early November.