Hi Christian, 2016-09-21 Christian König <christian.koenig@xxxxxxx>: > Am 21.09.2016 um 13:36 schrieb Gustavo Padovan: > > From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > > > > If the fences in the fence_array signal on the fence_array does not have > > signalling enabled num_pending will not be updated accordingly. > > > > So when signaling is disabled check the signal of every fence with > > fence_is_signaled() and then compare with num_pending to learn if the > > fence_array was signalled or not. > > > > If we want to keep the poll_does_not_wait optimization I think we need > > something like this. It keeps the same behaviour if signalling is enabled > > but tries to calculated the state otherwise. > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx> > > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > First of all the patch is horrible wrong because fence_array_signaled() is > called without any locks held. So you can run into a race condition between > checking the fences here and enable signaling. Yes. it can, but I don't think the race condition is actually a problem. Maybe you have some use case that we are not seeing? > Additional to that I'm not sure if that is such a good idea or not, cause > fence_array_signaled() should be light weight and without calling > enable_signaling there is not guarantee that fences will ever signal. It is still lightweight for the case when signaling is enabled and fences can signal with signaling enabled or disabled so I don't see that as problem too. Gustavo _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
