On Thu, 10 Nov 2011 15:13:48 +0000, Dave Airlie <airl...@gmail.com> wrote: > On Tue, Nov 1, 2011 at 11:17 PM, Eric Anholt <e...@anholt.net> wrote: > > Reviewed-by: Brian Paul <bri...@vmware.com> > > Just as an aside and maybe some way to help me figure out why > > this break piglit windowoverlap test on r100, specifically the sub > window drawing stops working. > > I bisected to this and its definitely it, I suspect its missing > flushes or something in the radeon driver, ideas on the back of a > postcard.
Looks like we do have the required prepare_render happening in both of our readpixels driver hooks, though I'd rather see that move into maprenderbuffer. I've been poking around at some misc. failures on Intel while thinking about what might be wrong, and one thing I came up with is that for writes, we're not marking a dri2 front buffer as dirty. Of course, we're not doing any writes yet. The particular misc intel failure I've been working on is that fbo-sys-blit seems to lose the contents of the backbuffer during some of the frontbuffer operations. My current theory is that the app has asked for the DRI2 drawable to have front and back, then posts some damage to front, and then the compositor asks for the drawable with front, so dri2_update_drawable() in the server frees the backbuffer, and then the client for some reason asks for the drawables again, and a new back is allocated. But while I think this should be a possible failure mode, I'm failing at making a simple testcase for it.
pgpjkjzpWIXqO.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
