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

[Thomas Hellstrom]

Hi, Michel,

On 08/09/2017 08:36 AM, Michel Dänzer wrote:
> 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.

OK. I'll try to do that.

>
>
> On 08/08/17 03:48 PM, Thomas Hellstrom wrote:
>> Implement back-to-fake-front flips,
>> Fix EGL_BUFFER_PRESERVED path.
>> 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_COPY_OML will behave like EGL_BUFFER_PRESERVED.
>>
>> 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?

Agreed. I haven't done any measurements but my reasoning was that 
probably any performance loss would be mostly associated with the 
allocating itself, hence a short-lived problem once enough buffers are 
allocated. The copying would, at least on modern tiling hardware, 
probably not be a big loss since we don't flush.

>
> 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.
>
>
True. But there are some implications:

First, with GLX_SWAP_COPY_OML, reusing the back buffer means we need to 
disable server-side page-flipping, otherwise the buffer would never be 
idle. Second, if we have a fake front, there will be at least one copy 
anyway. So in essence we need to disable server-side page-flipping and 
might not gain anything in the end if using a fake front.

With GLX_SWAP_EXCHANGE_OML, we'd be reusing the old fake front which 
will, after a delay, always be idle. Also we don't need an extra copy so 
the only loss will be a delay which might impact latency-sensitive 
applications. I don't expect SWAP_EXCHANGE will be used much anyway and 
even if we enable it in st/dri, it won't be advertised until the server 
side AIGLX starts to use the image loader extension or we rewrite the 
GLX fbconfig selection.

What do you think of adding a driConf option to select "wait for 
backbuffer idle in swapbuffers"

/Thomas