[Mesa-dev] [PATCH 0/2] First attempt at asynchronous SwapBuffers
Marek Olšák
maraeo at gmail.com
Wed Nov 14 19:43:21 PST 2012
Hi,
this series adds a new DRI2 extension to the libGL-Mesa interface, which consolidates the 3 flushes (glFlush, drawable flush, throttling) into one flush call like my previous patch series did, but it also allows thread offloading of SwapBuffers.
The motivation for the thread offloading is that it increases performance for some CPU-bound games (e.g. openarena) and the fact that the radeon gallium driver can already offload a context flush, which hides *a lot* of kernel overhead and is the main reason behind all this (the swap must be done in the driver thread for the offloading to work). Last but not least, we can use the extension for better thread offloading of OpenGL or Gallium (or both).
The idea is that the swap is performed in the driver-private thread. libGL only tells the driver it can offload the flush and sets a callback function, which swaps buffers and is called in the driver-private thread after flushing is finished. By the time the buffers are swapped, some GL commands for the next frame might have already been executed. The driver has to make sure that any new rendering won't get ahead of the swapping.
For the asynchronous SwapBuffers to work, there must be a separate X connection, because Xlib isn't thread-safe at all.
Now the bad news. The DRI invalidate events may be received too late. We can't wait for the events in glXSwapBuffers, because that would defeat the whole purpose of thread offloading. For normal apps, that only happens when the window is resized, so only the next rendered frame is likely to contain garbage.
Compositors don't work very well with this. I think it's because of the invalidate events not being received in time. As a temporary solution, I turn off asynchronous SwapBuffers if dri2_bind_tex_image is called, which should cover all compositors that either directly or indirectly use GLX.
I am open to suggestions how to resolve the last issue in a cleaner way. There are no piglit regressions and all apps seem to work. I'll send patches for gallium if we agree that this is a good idea.
Please review.
Marek
More information about the mesa-dev
mailing list