<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 8, 2018 at 8:19 AM, Kenneth Graunke <span dir="ltr"><<a href="mailto:kenneth@whitecape.org" target="_blank">kenneth@whitecape.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Tuesday, May 8, 2018 8:07:36 AM PDT Jason Ekstrand wrote:<br>
> On Mon, May 7, 2018 at 11:44 PM, Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>><br>
> wrote:<br>
> <br>
> > On Monday, May 7, 2018 12:49:32 PM PDT Jason Ekstrand wrote:<br>
> > > ---<br>
> > >  src/mesa/drivers/dri/i965/<wbr>gen7_misc_state.c | 3 ++-<br>
> > >  1 file changed, 2 insertions(+), 1 deletion(-)<br>
> > ><br>
> > > diff --git a/src/mesa/drivers/dri/i965/<wbr>gen7_misc_state.c<br>
> > b/src/mesa/drivers/dri/i965/<wbr>gen7_misc_state.c<br>
> > > index 1ce7658..1508473 100644<br>
> > > --- a/src/mesa/drivers/dri/i965/<wbr>gen7_misc_state.c<br>
> > > +++ b/src/mesa/drivers/dri/i965/<wbr>gen7_misc_state.c<br>
> > > @@ -195,7 +195,8 @@ const struct brw_tracked_state gen7_depthbuffer = {<br>
> > >        .mesa = _NEW_BUFFERS |<br>
> > >                _NEW_DEPTH |<br>
> > >                _NEW_STENCIL,<br>
> > > -      .brw = BRW_NEW_BATCH |<br>
> > > +      .brw = BRW_NEW_AUX_STATE |<br>
> > > +             BRW_NEW_BATCH |<br>
> > >               BRW_NEW_BLORP,<br>
> > >     },<br>
> > >     .emit = brw_emit_depthbuffer,<br>
> > ><br>
> ><br>
> > Changes like this warrant an explanation - is this fixing any known<br>
> > issues?  Found by inspection?<br>
> ><br>
> > I was surprised to see this, as BRW_NEW_AUX_STATE is usually about color<br>
> > surfaces - CCS_E compression, CCS_D fast clears...not HiZ.  But I see<br>
> > that intel_miptree_make_shareable might deal with HiZ...as does depth<br>
> > clear values...as does set_aux_state...so it certainly seems plausible.<br>
> ><br>
> > Still, I'm curious to know if you were thinking of anything specific.<br>
> ><br>
> <br>
> No, I don't know of anything specific.  I found it while I was working on<br>
> the rest of this series and thought it seemed off.  In particular, if we do<br>
> a trivial depth clear clear (which doesn't actually clear but just changes<br>
> the clear color), we may not get 3DSTATE_CLEAR_PARAMS updated.<br>
> <br>
<br>
</div></div>Ahh, right, that includes 3DSTATE_CLEAR_PARAMS...we probably do want<br>
this then.  Maybe record that and some hand waving in the commit<br>
message.<br>
</blockquote></div><br></div><div class="gmail_extra">I've added the following:<br></div><div class="gmail_extra"><br>    Certain things can change the aux usage or fast clear color of a depth<br>    surface and we want to re-emit if that happens.  For instance, if you do<br>    a fast depth clear of an already clear depth surface, we will just set<br>    the clear color and not do anything else.  In that case, we could fail<br>    to re-emit 3DSTATE_CLEAR_PARAMS and not get the new fast-clear color.<br><br></div></div>