From pekka.paalanen at haloniitty.fi Tue Apr 1 07:13:30 2025 From: pekka.paalanen at haloniitty.fi (Pekka Paalanen) Date: Tue, 1 Apr 2025 10:13:30 +0300 Subject: Is Mesa EGL triple buffered by default? In-Reply-To: References: <20250331111314.4013abef@eldfell> Message-ID: <20250401101330.5c912d42@eldfell> On Mon, 31 Mar 2025 11:02:46 -0500 Charlie McMackin wrote: > Thanks again for your helpful explanations! > > On Mon, Mar 31, 2025 at 3:13?AM Pekka Paalanen > 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: