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

[Michel Dänzer]

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?


> 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.


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