On Fri, Jan 13, 2012 at 09:10:15AM +0000, Dave Airlie wrote:
> On Sun, Dec 18, 2011 at 4:22 PM, Ville Syrjälä <syrj...@sci.fi> wrote:
> > Ever since xserver commit 531869448d07e00ae241120b59f3aaaa5709d59c,
> > the server no longer sends invalidate events to clients, unless they
> > have performed a GetBuffers request since the drawable was last
> > invalidated.
> >
> > If the drawable gets invalidated immediately after the GetBuffers
> > request was processed by the X server, it's possible that Xlib
> > will process the invalidate event while waiting for the GetBuffers
> > reply. So the server, thinking the client knows that the buffers
> > are invalid, is waiting for another GetBuffers request before
> > sending any more invalidate events. The client, on the other hand,
> > believes the buffers to be valid, and thus is expecting to receive
> > another invalidate event before it has to send another GetBuffers
> > request. The end result is that the client never again sends
> > a GetBuffers request.
> >
> > To avoid this problem, take a snapshot of lastStamp before
> > doing GetBuffers, and retry if the snapshot and the current
> > lastStamp no longer match after the GetBuffers reply has been
> > processed.
> >
> > Signed-off-by: Ville Syrjälä <syrj...@sci.fi>
> > ---
> > It looks like master should already handle this, as there's a
> > retry loop inside st_framebuffer_validate(). I didn't test that
> > in practice though.
>
> I'd really like to know if master can handle it before pulling a patch
> that isn't in master into 7.11.
I now managed to test master as well, and in fact it's also affected
by this bug.
After thinking about it a bit more I can see why that is.
st_framebuffer_validate() has the retry loop all right, but when it
calls dri_st_framebuffer_validate() during the retry,
dri_st_framebuffer_validate() thinks that the buffers are valid and
doesn't call allocate_textures(). Hence the retry loop actually does
nothing useful in this case.
So the 7.11 fix can be applied to master as well (the patch applies to
master cleanly), or we could go for a slightly more simple fix for
master due to the pre-existing retry loop. I'll leave that decision up
to someone else.
This is the simple approach:
diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
b/src/gallium/state_trackers/dri/common/dri_drawable.c
index 65b3d04..6effb11 100644
--- a/src/gallium/state_trackers/dri/common/dri_drawable.c
+++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
@@ -53,6 +53,7 @@ dri_st_framebuffer_validate(struct st_framebuffer_iface
*stfbi,
unsigned statt_mask, new_mask;
boolean new_stamp;
int i;
+ unsigned int lastStamp;
statt_mask = 0x0;
for (i = 0; i < count; i++)
@@ -66,7 +67,8 @@ dri_st_framebuffer_validate(struct st_framebuffer_iface
*stfbi,
* client stamp. It has the value of the server stamp when last
* checked.
*/
- new_stamp = (drawable->texture_stamp != drawable->dPriv->lastStamp);
+ lastStamp = drawable->dPriv->lastStamp;
+ new_stamp = (drawable->texture_stamp != lastStamp);
if (new_stamp || new_mask || screen->broken_invalidate) {
if (new_stamp && drawable->update_drawable_info)
@@ -80,7 +82,7 @@ dri_st_framebuffer_validate(struct st_framebuffer_iface
*stfbi,
statt_mask |= (1 << i);
}
- drawable->texture_stamp = drawable->dPriv->lastStamp;
+ drawable->texture_stamp = lastStamp;
drawable->texture_mask = statt_mask;
}
To verify my bugfix I used xtrace like so:
xtrace -n -k | tee mesa.log | grep -B1 Invalidate | grep Get
When the bug is tripped that will print the GetBuffers reply that was
being processed when the "bad" InvalidateBuffers event was received.
Using that xtrace incantation and glxgears I verified that both the
original patch and the simple patch fix the bug.
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
