<div dir="ltr">On 29 May 2013 14:19, Ville Syrjälä <span dir="ltr"><<a href="mailto:syrjala@sci.fi" target="_blank">syrjala@sci.fi</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On Wed, May 29, 2013 at 01:39:00PM -0700, Paul Berry wrote:<br>
> I started this discussion with just some of the Intel folks, and Eric<br>
> suggested I bring it to the mesa-dev list.<br>
><br>
> The short version is: in my efforts to implement fast color clears on Intel<br>
> hardware, I've uncovered some problems with the fbo-sys-blit piglit test,<br>
> which I've traced to 3 bugs.  I could use some help with bug (2) below,<br>
> which I suspect is a bug in the X server.<br>
><br>
> ---------- Forwarded message (footnotes added) ----------<br>
><br>
> First of all, a brief summary of what fbo-sys-blit's piglit_display() does:<br>
><br>
> a. Clear the back buffer to green.<br>
> b. Copy the back buffer to the front buffer using a blit.<br>
> c. Clear the back buffer to red.<br>
> d. Read the contents of the front buffer to verify that it's green.<br>
><br>
> I've found three bugs:<br>
</div><snip><br>
<br>
Did you try this [1] patch from Chris? I had a similar patch in a<br>
private tree way back when, but for some reason I decided that it's not<br>
necessary, and hence didn't send it out. I can't actually recall why I<br>
came to that conclusion, nor can I think of a good reason now either.<br>
But it's been quite a while since I poked at any dri2 or composite stuff<br>
so I may be out of practice.<br>
<br>
[1] <a href="http://patchwork.freedesktop.org/patch/12111/" target="_blank">http://patchwork.freedesktop.org/patch/12111/</a> <br></blockquote><div> </div></div><div>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:<br><br></div><div>- 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.<br></div><div>-
 As a result of x server commit 3209b094 (which fixed 
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=28365">https://bugs.freedesktop.org/show_bug.cgi?id=28365</a>), a serial number 
change causes all of the drawable's buffers to be reallocated.<br></div><div>-
 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.<br><br></div><div>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 <a href="https://bugs.freedesktop.org/show_bug.cgi?id=28365">https://bugs.freedesktop.org/show_bug.cgi?id=28365</a> (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.<br><br></div><div>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. <br>
</div></div></div>