Ken, It would be nice to get that patch [1] in fairly soon -- master is currently unusable.
[1] http://cgit.freedesktop.org/~kwg/mesa/commit/?h=texturelock&id=51b6879849f1efcfb28a45a63c2230ad0b2292e7 Consider it: Reviewed-and-tested-by: Chris Forbes <chr...@ijw.co.nz> On Mon, Aug 18, 2014 at 9:36 AM, Chris Forbes <chr...@ijw.co.nz> wrote: > Yes, that fixes it. > > On Mon, Aug 18, 2014 at 9:01 AM, Kristian Høgsberg <hoegsb...@gmail.com> > wrote: >> On Sun, Aug 17, 2014 at 11:36:55PM +1200, Chris Forbes wrote: >>> This commit (2f28a0dc2 on master) causes various apps (at least >>> glxgears & vlc) to render garbage on my HSW GT3e. There are regular >>> vertical bands of black pixels; on some frames, a few blocks of pixels >>> within those bands are present; on others, not. >> >> Is that fixed by >> >> >> http://cgit.freedesktop.org/~kwg/mesa/commit/?h=texturelock&id=51b6879849f1efcfb28a45a63c2230ad0b2292e7 >> >> ? >> >> The docs say "When performing a render target resolve, PIPE_CONTROL with >> end of pipe sync must be delivered.", which doesn't make it clear whether >> it's before or after. A RC flush before doing the resolve certainly makes >> sense, since you'd expect the resolve operation to have to read back from >> the MCS. >> >> Kristian >> >>> >>> On Tue, Aug 12, 2014 at 5:45 PM, Kristian Høgsberg <hoegsb...@gmail.com> >>> wrote: >>> > On Mon, Aug 11, 2014 at 08:46:23PM -0400, Ilia Mirkin wrote: >>> >> On Mon, Aug 11, 2014 at 8:29 PM, Kristian Høgsberg <k...@bitplanet.net> >>> >> wrote: >>> >> > diff --git a/src/mesa/drivers/dri/i965/intel_tex_copy.c >>> >> > b/src/mesa/drivers/dri/i965/intel_tex_copy.c >>> >> > index 97f1569..2456080 100644 >>> >> > --- a/src/mesa/drivers/dri/i965/intel_tex_copy.c >>> >> > +++ b/src/mesa/drivers/dri/i965/intel_tex_copy.c >>> >> > @@ -79,6 +79,8 @@ intel_copy_texsubimage(struct brw_context *brw, >>> >> > int dst_slice = slice + intelImage->base.Base.Face + >>> >> > intelImage->base.Base.TexObject->MinLayer; >>> >> > >>> >> > + _mesa_unlock_texture(&brw->ctx, intelImage->base.Base.TexObject); >>> >> > + >>> >> > /* blit from src buffer to texture */ >>> >> > if (!intel_miptree_blit(brw, >>> >> > irb->mt, irb->mt_level, irb->mt_layer, >>> >> > @@ -89,6 +91,8 @@ intel_copy_texsubimage(struct brw_context *brw, >>> >> > return false; >>> >> > } >>> >> > >>> >> > + _mesa_lock_texture(&brw->ctx, intelImage->base.Base.TexObject); >>> >> > + >>> >> > return true; >>> >> > } >>> >> >>> >> Just happened to notice in some aimless scrolling... you return above, >>> >> so in one path you don't relock the texture, but in the other you do. >>> >> Usually that sort of thing leads to trouble, but perhaps there's >>> >> something going on here which makes it OK. If that's the case, >>> >> probably deserves a comment. >>> > >>> > Nope, my bad. Thanks for catching that. >>> > >>> > Kristian >>> > _______________________________________________ >>> > mesa-dev mailing list >>> > mesa-dev@lists.freedesktop.org >>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
