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

[Thomas Hellstrom]

On 08/10/2017 05:27 AM, Michel Dänzer wrote:
> On 09/08/17 04:07 PM, Thomas Hellstrom wrote:
>> On 08/09/2017 08:36 AM, Michel Dänzer wrote:
>>> 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.
> Okay, you've convinced me. Any chance this patch can be split up as well
> though?
>

Yes, I'll try to split it up.

Thanks,
Thomas



>> What do you think of adding a driConf option to select "wait for
>> backbuffer idle in swapbuffers"
> Seems like overkill. Let's wait for actual problem reports before
> considering that.
>
>