EGL partial_update vs. swap_buffers_with_damage and amdgpu support
Pekka Paalanen
pekka.paalanen at haloniitty.fi
Mon Jan 27 09:28:58 UTC 2025
On Sun, 26 Jan 2025 10:37:39 -0600
Charlie McMackin <charliemac at endparen.com> wrote:
> On Sun, Jan 26, 2025 at 9:28 AM Pekka Paalanen
> <pekka.paalanen at haloniitty.fi> wrote:
> >
> > Not all GPUs benefit from the partial_update information, it
> > depends on the GPU hardware design. Usually so called "tiler" GPUs
> > can benefit from it, while "immediate mode" GPUs don't (I hope I
> > got the term right). AMD tends to be in the latter group.
> >
> Ah, this is definitely one key I didn't know. So, I shouldn't be
> missing out on any ability to only update damaged areas of a
> framebuffer without the partial_update extension...the main key is
> using buffer_age to determine what my render loop should draw and the
> other two are more for hinting to compositors that support it / are
> more nice-if-you-have-it?
Exactly.
If you don't have buffer_age, or it gives you zero as the age, or the
age is greater than the damage history you keep, you need to do a full
draw.
Alternatively, one could set the EGL surface attribute
EGL_SWAP_BEHAVIOR to EGL_BUFFER_PRESERVED when supported, and always
draw only the latest updates, but it also implies that the EGL
implementation needs to do a full copy of the buffer at each swap.
Using buffer_age can be more optimal than that, at the cost of
increased code complexity.
A word of caution: ordering your EGL calls is very important when you
need to resize the window. When you query buffer_age, EGL determines
which buffer you are going to draw to next. Once the next buffer is
determined, you cannot resize it. Any resize call will apply after the
next swap.
Also any OpenGL drawing command will determine the next buffer if it
wasn't already, and I assume this is well-known, but an EGL call doing
it can be a surprise. There might be other EGL calls doing it as well,
so the most reliable place to resize is immediately after a swap.
> Thanks again!
No problem,
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/20250127/5ccb010d/attachment.sig>
More information about the mesa-users
mailing list