[Mesa-dev] [PATCH 2/2] i965: Fix brw_finish_batch to grow the batchbuffer.

[Chris Wilson]

Quoting Chris Wilson (2017-09-19 09:38:54)
> Quoting Kenneth Graunke (2017-09-18 21:44:57)
> > On Monday, September 18, 2017 11:14:35 AM PDT Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2017-09-18 18:56:57)
> > > > @@ -904,13 +914,6 @@ _intel_batchbuffer_flush_fence(struct brw_context *brw,
> > > >                brw->batch.state_relocs.reloc_count);
> > > >     }
> > > >  
> > > > -   brw_finish_batch(brw);
> > > > -
> > > > -   intel_upload_finish(brw);
> > > > -
> > > > -   /* Check that we didn't just wrap our batchbuffer at a bad time. */
> > > > -   assert(!brw->no_batch_wrap);
> > > 
> > > Keep a sanity check !brw->no_batch_wrap after flushing?
> > 
> > I moved the assert(!brw->no_batch_wrap) before brw_finish_batch, so we'd
> > still guard against flushing-while-flushing.  We have to do that because
> > brw_finish_batch() now whacks it.  I could leave one here too, if you
> > like, but that would only guard against brw_finish_batch() bugs, rather
> > than bugs in callers...so it didn't seem as useful...
> 
> I was thinking of a bug here would be carried until the next update.
> Something like an infinite stream of glMemoryBarrier wouldn't reset
> no_batch_wrap. I was trying to capture the invariant in that every new
> batch starts with no_batch_wrap = false, a slightly different statement
> that we should never flush a batch with no_batch_wrap = true.

Regardless, the series looks sound, although I missed the recursion
before,
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris