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 <ch...@chris-wilson.co.uk> -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
