Re: Is Mesa EGL triple buffered by default?

--Sig_/lQryu.oCxPFzkOTTTHVLOZg
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 31 Mar 2025 11:02:46 -0500
Charlie McMackin <[email protected]> wrote:

> Thanks again for your helpful explanations!
>=20
> On Mon, Mar 31, 2025 at 3:13=E2=80=AFAM Pekka Paalanen
> <[email protected]> wrote:
>=20
> > 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.
> > =20
>=20
> 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.
>=20
> > > 2. If so, is there a setting that might make it strictly double buffe=
red? =20
> >
> > I'm not aware of any. =20
>=20
> Good to know. Thanks.
>=20
> >
> > 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. =20
>=20
> 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.
>=20
> > You should handle buffer ages up to at least 3, maybe 4. =20
>=20
> 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.
>=20
> > 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.
> > =20
>=20
> 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? =20
>=20
> :) 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

--Sig_/lQryu.oCxPFzkOTTTHVLOZg
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmfrkhoACgkQI1/ltBGq
qqexFg//V4WgDVYiMNWA703W6v6BltlEkpv6nIK6g9aiyswoM7Gw/KWDGCQEJQfc
DbABsqvqKdZLOCl9zh26UoCoqaO5EYVbVWho/Alq4iPwWPtfcdtXl3+4LXGvx8Az
Tc4lQHK3ya8xmes1ZpCoRVupIebCRLQ80ccOQCAF16PyVrcglyo3sFftaSerpGa8
c2E4/ctrM01hhlueBcHNZ99UoZnbioye0SQ225o43A+2fhXmgVb5ixCR0scnbuui
FvOiiV6vhJE36OnpwfZzesHLTDdgdXQZq6Jnh1lr4DYdaG46EWvW5cPP2XvDHbw/
pb2KxznFNfxHJ+UwoiKHHS66LPiMwyebJvX2cQ7bqkJTYBeSgmdDzAJWBJNtIQvp
akB4bU5aqfjMVo3ZdAJQSHxpcFtCT213flAoHOlzTwJJSVMQFyoaJNp2tNWHEQ8K
2p8nOWN9AJ/fHIBfS/WT+t0szVYvJ/tdTZCluZuKsAy8KLolegOWjyp6yM9RVc96
LReAJIWO4MRrYorPD/cilTq7VgiO4UyRJhprv/+0CwnJ38NAlKqOSSdvDJXG7vcX
HzoQNUT6elJAT2ZKia89aSStGpFGfN+BFjqweWkTwBoRuH8AtgIVoTgOauqsVBGh
bLYUocOTbtVyWc4q5qmAJmGEcSMGnxK2slZShMPTYJkg6DEZjIA=
=Q5VH
-----END PGP SIGNATURE-----

--Sig_/lQryu.oCxPFzkOTTTHVLOZg--