[Mesa-dev] Bugs in fbo-sys-blit (problems with fake front and missing invalidates)

[Paul Berry]

On 29 May 2013 14:19, Ville Syrjälä <syrjala at sci.fi> wrote:

> On Wed, May 29, 2013 at 01:39:00PM -0700, Paul Berry wrote:
> > I started this discussion with just some of the Intel folks, and Eric
> > suggested I bring it to the mesa-dev list.
> >
> > The short version is: in my efforts to implement fast color clears on
> Intel
> > hardware, I've uncovered some problems with the fbo-sys-blit piglit test,
> > which I've traced to 3 bugs.  I could use some help with bug (2) below,
> > which I suspect is a bug in the X server.
> >
> > ---------- Forwarded message (footnotes added) ----------
> >
> > First of all, a brief summary of what fbo-sys-blit's piglit_display()
> does:
> >
> > a. Clear the back buffer to green.
> > b. Copy the back buffer to the front buffer using a blit.
> > c. Clear the back buffer to red.
> > d. Read the contents of the front buffer to verify that it's green.
> >
> > I've found three bugs:
> <snip>
>
> Did you try this [1] patch from Chris? I had a similar patch in a
> private tree way back when, but for some reason I decided that it's not
> necessary, and hence didn't send it out. I can't actually recall why I
> came to that conclusion, nor can I think of a good reason now either.
> But it's been quite a while since I poked at any dri2 or composite stuff
> so I may be out of practice.
>
> [1] http://patchwork.freedesktop.org/patch/12111/
>

Thanks for the suggestion.  Ultimately, this didn't turn out to fix the
problem, but it gave a helpful starting point for me and Eric to debug
yesterday.  Here's what we found:

- Something (we're not sure exactly what) is causing the DRI2Drawable's
serialNumber to change when the window gets mapped and compositing is in
use.  This is not terribly surprising, since serial numbers change under a
lot of circumstances.
- As a result of x server commit 3209b094 (which fixed
https://bugs.freedesktop.org/show_bug.cgi?id=28365), a serial number change
causes all of the drawable's buffers to be reallocated.
- However, whatever caused the serialNumber to change didn't cause an
invalidate message to be sent to the client, so Mesa doesn't find out that
it needs to request buffers before it starts rendering the frame.

We believe that commit 3209b094 is causing the server to overzealously
reallocate buffers, and that we need to revert it and find a less broad fix
for https://bugs.freedesktop.org/show_bug.cgi?id=28365 (if it still
exists--a lot of other fixes got made in the meantime which might have
addressed the true cause of the bug).  Eric is going to work on doing that
while I pursue the remaining issues from my original email.

Note: in the process of debugging we discovered another scenario that can
cause fake front buffering to be lost: if, while the fake front buffer is
dirty, Mesa makes a request for just the back buffer, the X server will
throw away the fake front buffer.  I'll make a piglit test and a fix for
this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130531/8c93d3c8/attachment.html>