[Mesa-dev] Bug with glBlitFramebufferEXT(), and a piglit test for it

Timothy Arceri t_arceri at yahoo.com.au
Tue Oct 22 09:11:19 CEST 2013

Hi Federico,

Just FYI you should send the piglit test to the piglit mailing list:

Also to allow easy review you should use git send-email rather than
attaching it to the email.

Timothy Arceri

On Mon, 2013-10-21 at 17:37 -0500, Federico Mena Quintero wrote:
> Hello, everyone,
> Attached is a new test for piglit which exposes a bug in Mesa's
> software rendering (and another bug in hardware rendering, but that's
> not its main purpose).
> The bug is as follows.  With software rendering, after doing a buffer
> swap, glBlitFrameBufferEXT() appears to to copy the whole framebuffer
> instead of just the specified region.  This breaks clutter and cogl,
> since they keep track of a dirty region themselves, and they use blits
> instead of full buffer swaps to avoid updating the whole display on
> every frame unnecessarily.
> What is happening is actually a bit more complicated.
> glBlitFrameBufferEXT()'s basic machinery works correctly, but if there
> has been a buffer swap before it, the following happens:
> 1. Draw some stuff (say, to GL_BACK)
> 2. Swap buffers.  As far as I can tell, this just causes an
> XPutImage() from the GL_BACK buffer to the X window.
> 3. Draw some stuff to GL_BACK.
> 4. Do glBlitFrameBufferEXT() from GL_BACK to GL_FRONT with the area you
> are interested in.
> 5. Internally, Mesa sees that the buffer for GL_FRONT has not been
> created yet, so it creates it and does the blit.
> 6. Do glFlush() so that GL_FRONT actually gets sent to the screen.  This
> causes an XPutImage() of the *whole* of GL_FRONT, thus giving
> incorrect results - the area that should have been updated is the one
> from (4), i.e. just the blit.
> If you run the test program with hardware acceleration, it will work
> correctly.  But if you run it with LIBGL_ALWAYS_SOFTWARE=1, it will
> fail.
> For a related bug, do the following:  in the test program change the
> line that says
> from 1 to 0.  Run the program again; this time it will work correctly
> with software rendering, but at least on my box it fails with hardware
> rendering (Intel).
> I don't know enough about Mesa's internals to fix this quickly.  Any
> help is appreciated.
> Thanks,
>   Federico
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

More information about the mesa-dev mailing list