Bug 38123

(In reply to comment #0)
> I have a piece of code that reads the front buffer right after swap buffers,
> like this
> 
> glxSwapBuffer()
> glGetintegerv)(GL_READ_BUFFER, &read_buffer);
> glReadBuffer(GL_FRONT)
> glReadPixels()
> glReadBuffer(read_buffer)
> 
> This code works on nvidia, but on intel I just get black pixels in the buffer
> filled by glReadPixels.
> 
> If I instead I read GL_BACK (which according to the spec should have undefined
> contents) on intel I get the image I would expect in the front buffer.

Which is okay.  The spec says it's undefined because there are two ways that swap is implemented: page flipping and copying.  In the page flipping case, the back buffer will traditionally have the contents from 2 frames back (though this in not the case with DRI2).  In the copying case, the back buffer will still have the same contents.  Guess which is being done here. :)

> The spec says:
> 
> "glXSwapBuffers performs an implicit glFlush before it returns. Subsequent
> OpenGL commands may be issued immediately after calling glXSwapBuffers, but are
> not executed until the buffer exchange is completed."
> 
> It looks like instead glReadPixels is executed before the exchange is completed

Right, and that is a bug.  It seems like this should have been fixed by the patch below.  Can you confirm?

commit 23b6f9606dc247488835745668b3686218612536
Author: Eric Anholt <eric@anholt.net>
Date:   Tue May 31 12:32:06 2011 -0700

    intel: Implement glFinish() correctly by waiting on all previous rendering.
    
    Before, we were waiting for (most of) the current framebuffer to be
    done, which is not quite the same thing.

(In reply to comment #1)
> Which is okay.  The spec says it's undefined because there are two ways that
> swap is implemented: page flipping and copying.

Sure, I didn't mean to imply that it was a bug, I was just stating it in case it was useful info.

> > 
> > It looks like instead glReadPixels is executed before the exchange is completed
> 
> Right, and that is a bug.  It seems like this should have been fixed by the
> patch below.  Can you confirm?
> 

Once I have compiled mesa do I just need to swap the system's libGL.so with the compiled one or do I need a full install also including the intel driver?

I compiled mesa master and installed libGL.so.1.2 and i965_dri.so but I still see the problem

glFinish() shouldn't be related.

However, I can't reproduce the problem, and I reviewed that glReadPixels should be doing the right thing.  I've been making variants of piglit's read-front test trying to trigger any sort of failure, with no luck.  You might know more of what the rest of your code is doing and have more luck, though, if you could build us a testcase there.  The sequence of rendering calls between your swap+reads is likely to be important.

http://cgit.freedesktop.org/piglit/tree/tests/general/read-front.c

On closer inspection when running this whole application I think I may end up in software rendering mode... maybe that is affected by the same bug? For what it concerns intel I guess you can consider this fixed, if I can produce a testcase I'll reopen the bug

Bing is web browser and this is different mode app http://deletebinghistory.com no sign up and charges here,easily to install this app.