Re: Is Mesa EGL triple buffered by default?

--Sig_/0EIA4ixjPWT9R.Ydw94lKGU
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 29 Mar 2025 15:48:39 -0500
Charlie McMackin <[email protected]> wrote:

> Hi all,
>=20
> I have 2 main questions, context to follow:
>=20
> 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.
>=20
> 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

--Sig_/0EIA4ixjPWT9R.Ydw94lKGU
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmfqTpoACgkQI1/ltBGq
qqcnIA//T/19ygY813jv7dljMA1xJWoILLEgRufUG6iUUW6gAmjCa5D7RFQIGJqp
TVw+2c+UoOvGyA40oJoUm/VN3ulq+YdiWA5TPwrqzryai5nFNdimzunmb3Q5O+zx
I8Sacs3nouuvD8I6coUf+CHcBCcOPWfvdzKNBl154BaHInV2X8gwHwKY/Yye85B+
gnXkm/n9oeUPqULJ/PRHlPPHGAqaBbpZrnHNBUbE1/IHyHDWXXyoDGyw9225faqr
ke1rYdzl7G7tEoxogubO8DURgMsSwqmTNlatSy+6OYjGFUcALFLald4LInIbaPVs
hZDbUgBI4RoExA3CkV0rMHcpslfktpgQudSHsoGWh4vhkBCp629W7HwEQuJDJRRN
nehI8qU6LDuNweCzFeFiMohtVvB5yIngpEkvbHY8zsKvlXZTT0cxYuR3H+m8dgl2
qB6fow7OLCq7rrwEAcyAo9eMgbyUgbQlHbGWMNP6SpvfajvfYbUQ5XIRgqkGzV+y
p0DBoK7aUBikxMSmCCeDHDvYdpwtCtQCkA+Y/jExx+IwxhetnDSPETeW8CEjgCQA
7PNBpgh9le5WYnEZaAZ1fKLUg26MzI7hAzXqXfQgOCkO7tYdWXhgZNqa6GTxC3Y4
3/X+R6zfDbqiuw1wU5mTQ44z4kLuMnho4a1NImMGkRMUuJk9GzY=
=B/Dg
-----END PGP SIGNATURE-----

--Sig_/0EIA4ixjPWT9R.Ydw94lKGU--