[Mesa-dev] [PATCH 13/17] swrast: Drop the global mapping of buffers across glReadPixels().
Eric Anholt
eric at anholt.net
Fri Nov 11 08:27:25 PST 2011
On Thu, 10 Nov 2011 15:13:48 +0000, Dave Airlie <airlied at gmail.com> wrote:
> On Tue, Nov 1, 2011 at 11:17 PM, Eric Anholt <eric at anholt.net> wrote:
> > Reviewed-by: Brian Paul <brianp at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20111111/f0a20225/attachment.pgp>
More information about the mesa-dev
mailing list