On Mon, Sep 24, 2018 at 01:58:12PM +0200, Christian König wrote: > The reservation object shared slot function only allowed to reserve one slot at a time. > > Improve that and allow to reserve multiple slots to support atomically submission to multiple engines. I think you can do this already, just don't drop the ww_mutex lock. And I also think that invariant still holds, if you drop the ww_mutex lock your fence slot reservation evaporates. Your new code is just a bit more convenient. Could we check/enforce this somehow when WW_MUTEX debugging is enabled? E.g. store the ww_mutex ctx in the reservation (we can dig it out from under the lock), and then check that the lock holder/ctx hasn't changed when adding all the fences? I think with multiple fences getting added atomically some more debug checks here would be good. Another one: Do we want to insist that you either add all the fences, or none, to make this fully atomic? We could check this when unlocking the reservation. Kinda hard to guess what your exact use-case here is. All this would ofc be compiled out for !WW_MUTEX_DEBUG kernels. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
