Mesa: Thread Offloading, Asynchronous SwapBuffers
Marek Olšák continues to work on Mesa/Gallium3D performance improvements. Marek's latest work is on implementing a-synchronous SwapBuffers and to allow for thread offloading of SwapBuffers via a new DRI2 extension to the libGL-Mesa interface.
Marek explains his new Mesa patches with, "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."
However, there are some issues with the work in its current form in terms of DRI invalidate events potentially being received too late and the a-synchronous SwapBuffers don't work too well with compositing window managers.
This patch work from Marek is still being discussed and can be found on the mesa-dev list.
Marek explains his new Mesa patches with, "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."
However, there are some issues with the work in its current form in terms of DRI invalidate events potentially being received too late and the a-synchronous SwapBuffers don't work too well with compositing window managers.
This patch work from Marek is still being discussed and can be found on the mesa-dev list.
5 Comments