Is Mesa EGL triple buffered by default?

[Pekka Paalanen]

On Mon, 31 Mar 2025 11:02:46 -0500
Charlie McMackin <charliemac at endparen.com> wrote:

> Thanks again for your helpful explanations!
> 
> On Mon, Mar 31, 2025 at 3:13 AM Pekka Paalanen
> <pekka.paalanen at haloniitty.fi> wrote:
> 
> > 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.
> >  
> 
> Thank you! This is very helpful to know for my debugging going
> forward. I didn't know about the resource pool behavior for the
> framebuffers.
> 
> > > 2. If so, is there a setting that might make it strictly double buffered?  
> >
> > I'm not aware of any.  
> 
> Good to know. Thanks.
> 
> >
> > 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.  
> 
> I've been testing this against the Sway compositor so far.  It sounds
> like double buffering could result in a slow or  laggy experience but
> I'm ok with that as a first step as long as the two frames look
> correct.
> 
> > You should handle buffer ages up to at least 3, maybe 4.  
> 
> That is my eventual goal but it will take a little more work to get
> that state tracking integrated, so I have been aiming for double
> buffering first.
> 
> > 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.
> >  
> 
> So, querying the buffer age will trigger a request to the EGL
> framebuffer pool and the pool might not "see" the freed up framebuffer
> if I make the query right after a swap, thus it will create a new
> buffer. Am I understanding that well? I've noticed that resizing
> resets the age to 0 and I recall your previous response on a separate
> thread about resizing.. but I'm not at the point of focusing on the
> resizing problem yet. I will keep it in mind.

Correct. Asking for buffer age later gives a little more time to get
some potential old buffer release delivered.

Age 0 means all buffer contents are undefined, and that is what newly
allocated buffers always start with. A new size needs new buffers.

> > What's your actual problem?  
> 
> :) Well I'm trying to implement an OpenGL immediate mode backend for
> an existing GUI library written in Common Lisp. This GUI library has
> support for double-buffering and rendering only the updated elements
> but so far my work-in-progress is still flashing because it looks like
> it's updating an older buffer. This happens on a window that remains
> the same size and is just responding to mouse hovering and
> highlighting a button, for example. I'm still learning lots about
> wayland, egl, and the gui library but once I get a better handle on
> the render loop, I hope to start working toward more modern OpenGL
> use.

Ok, that sounds very much like a damage tracking issue indeed, as you
have correctly identified.


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/20250401/c392ccb6/attachment.sig>