Is Mesa EGL triple buffered by default?

[Pekka Paalanen]

On Sat, 29 Mar 2025 15:48:39 -0500
Charlie McMackin <charliemac at endparen.com> wrote:

> Hi all,
> 
> I have 2 main questions, context to follow:
> 
> 1. Is Mesa EGL triple buffered by default?

eglSwapInterval() is the related API for that, although it is indirect
to the matter of how many buffers are being rotated. SwapInterval
controls blocking on the previous presentation, not the count of
buffers.

Mesa EGL Wayland platform always uses a pool of buffers that it expands
as necessary. When an EGL or GL API call needs a free buffer, after
potentially blocking based on SwapInterval, a buffer is pulled from the
pool. If the pool has none free, a new one is allocated. So EGL is not
even rotating buffers, like always swapping back and front, but just
pulling one from the pool.

> 2. If so, is there a setting that might make it strictly double buffered?

I'm not aware of any.

Strict double-buffering could even prevent you from reaching the
display frame rate when a Wayland compositor skips doing a copy on the
GPU and puts the client buffer straight to KMS (a.k.a direct scanout or
composite bypass). In order to get a buffer released by KMS, a new
buffer must be submitted and enter its hardware scanout cycle. Waiting
for that release is time the client could be spending on rendering the
next frame, both CPU and GPU wise. This happens especially in vsync'd
presentation in the compositor.

> ## Context
> - I am writing a Wayland/OpenGL/EGL application
> - Immediately after calling eglSwapBuffers I am querying the buffer age
> - Buffer age is consistently `3`

You should handle buffer ages up to at least 3, maybe 4.

Querying buffer age is a call that needs a new free buffer, btw. That
would be best done immediately before rendering rather than at the end
of swapping. It has consequences for resizing the surface, too.

> - the EGL surface type has the window bit set and renderable type has
> the opengl bit set
> - I have used tracing tools (ApiTrace) to the best of my knowhow and I
> don't see where I might be generating another frame.
> 
> 3. If the answers to 1 and 2 above are no, is there something I've
> missed or a better tool I could use to debug?

What's your actual problem?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-users/attachments/20250331/853eaf7d/attachment.sig>