[Mesa-dev] [PATCH 2/2] dri3: Swapbuffer update

Michel Dänzer michel at daenzer.net
Wed Aug 9 06:36:48 UTC 2017

Hi Thomas,

first of all, would it be possible to split these patches up a bit
further? At least patch 1 seems to contain several logical changes,
which makes it a bit difficult to review.

On 08/08/17 03:48 PM, Thomas Hellstrom wrote:
> Implement back-to-fake-front flips,
> Implement dri3 support for GLX_SWAP_EXCHANGE_OML and GLX_SWAP_COPY_OML.
> The back-to-fake-front flips will save a full buffer copy in the case of a
> fake front being enabled and GLX_SWAP_UNDEFINED_OML.
> Support for EGL_BUFFER_PRESERVED and GLX_SWAP_X_OML are mostly useful for
> things like glretrace if traces are capured with applications relying on a
> specific swapbuffer behavior.
> The EGL_BUFFER_PRESERVED path previously made sure the present was done as
> a copy, but there was nothing making sure that after the present,
> the same back buffer was chosen.
> This has now been changed so that if the previous back buffer is
> idle, we reuse it. Otherwise we grab a new and copy the contents and
> buffer age from the previous back buffer. Server side flips are allowed.
> GLX_SWAP_EXCHANGE_OML will behave similarly, except that we try to reuse the
> previous fake front as the new back buffer if it's idle. If not, we grab
> a new back buffer and copy the contents and buffer age from the old fake front.

I'm not sure it's worth copying the contents of the desired next back
buffer to a different one and using that instead. There might be cases
where doing so results in lower performance than simply using the
desired back buffer anyway. Have you made any measurements WRT this?

With EGL_BUFFER_PRESERVED/GLX_SWAP_COPY_OML, always re-using the same
back buffer means that the client only needs to allocate one back
buffer, resulting in lower graphics memory consumption.

Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

More information about the mesa-dev mailing list