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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev