Federico Mena Quintero <[email protected]> writes: > 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.
Ouch. Doing anything to GL_FRONT is really punitive to performance in DRI2. Any chance we could convince clutter to use GLX_MESA_copy_sub_buffer/EGL_NV_post_sub_buffer instead? Then you wouldn't get that fullscreen copy. Of course, the thing clutter really needs is buffer_age. We need to write tests so we can actually merge some code for it. > 5. Internally, Mesa sees that the buffer for GL_FRONT has not been > created yet, so it creates it and does the blit. Sounds like we have a problem here of not updating our frake front with the current real front contents. I forget what the state of things was, but at one point I recall issues with vsynced swaps versus copies from front to fake front.
pgpCbP73clh_J.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
