Re: Improve reservation object shared slot function

From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Subject: Re: Improve reservation object shared slot function
Date: Mon, 24 Sep 2018 17:03:19 +0200	[thread overview]
Message-ID: <20180924150319.GV11082@phenom.ffwll.local> (raw)
In-Reply-To: <20180924115819.2116-1-christian.koenig@amd.com>

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel