Hi, some applications use successive calls to glReadPixels to read data back. This typically involves a GPU-based blit for each call for de-tiling or format conversions (e.g. BGRA -> RGBA). Even when the _mesa_readpixels path is used, such a blit tends to be hidden behind the transfer operations. The overhead is rather bad for performance, since we have to wait for GPU idle each time.
This patch series implements a cache which heuristically does a blit of the entire framebuffer into a temporary texture once, which is then re-used by immediately following calls to glReadPixels. The cache remains disabled for drivers that do not prefer blit based texture transfers, i.e. softpipe/llvmpipe. Aside from a client's application, this also affects ~1400 piglit tests, which tend to see speedups of 5-10% with this cache in my tests. While looking for places that invalidate the cache, I also noticed a few additional spots where I believe the bitmap cache needs to be flushed. I put those first in this series. Please review! Thanks, Nicolai -- src/mesa/state_tracker/st_atom_framebuffer.c | 1 + src/mesa/state_tracker/st_cb_bitmap.c | 3 + src/mesa/state_tracker/st_cb_blit.c | 1 + src/mesa/state_tracker/st_cb_clear.c | 1 + src/mesa/state_tracker/st_cb_compute.c | 4 + src/mesa/state_tracker/st_cb_copyimage.c | 4 + src/mesa/state_tracker/st_cb_drawpixels.c | 2 + src/mesa/state_tracker/st_cb_drawtex.c | 1 + src/mesa/state_tracker/st_cb_fbo.h | 2 + src/mesa/state_tracker/st_cb_readpixels.c | 244 +++++++++++++---- src/mesa/state_tracker/st_cb_texture.c | 12 + src/mesa/state_tracker/st_context.c | 3 + src/mesa/state_tracker/st_context.h | 11 + src/mesa/state_tracker/st_draw.c | 1 + src/mesa/state_tracker/st_draw_feedback.c | 1 + src/mesa/state_tracker/st_gen_mipmap.c | 4 + 16 files changed, 237 insertions(+), 58 deletions(-) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
