Quoting Chris Wilson (2017-06-09 14:01:34) > The fence bo may be reused as an input fence to another batch, which > will cause us to treat it as busy until that subsequent batch is idle. > We only need to check if the fence has been signaled, which we can do by > checking the write status of the fence bo -- when the write is > completed, the fence is signaled. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Kenneth Graunke <kenn...@whitecape.org> > Cc: Matt Turner <matts...@gmail.com> > --- > src/mesa/drivers/dri/i965/brw_sync.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_sync.c > b/src/mesa/drivers/dri/i965/brw_sync.c > index a8356c304f..427108610d 100644 > --- a/src/mesa/drivers/dri/i965/brw_sync.c > +++ b/src/mesa/drivers/dri/i965/brw_sync.c > @@ -179,7 +179,7 @@ brw_fence_has_completed_locked(struct brw_fence *fence) > return false; > } > > - if (brw_bo_busy(fence->batch_bo)) > + if (brw_bo_write_busy(fence->batch_bo)) > return false;
This is wrong. I was thinking of vk fence bo which are separate entities, signaled with a dummy write. GL is using the batch as its fence bo and so never flags it with a dummy write. We must there always wait/check for exclusive access here. -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
