[Mesa-dev] [PATCH 12/12] i965: Implement fast color clears using meta operations

[Chris Forbes]

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 <chrisf at ijw.co.nz>

On Mon, Aug 18, 2014 at 9:36 AM, Chris Forbes <chrisf at ijw.co.nz> wrote:
> Yes, that fixes it.
>
> On Mon, Aug 18, 2014 at 9:01 AM, Kristian Høgsberg <hoegsberg at 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 <hoegsberg at 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 <krh at 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 at lists.freedesktop.org
>>> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev