On 15 March 2017 at 10:47, Dave Airlie <airlied@xxxxxxxxx> wrote: > On 14 March 2017 at 19:30, Christian König <deathsimple@xxxxxxxxxxx> wrote: >> Am 14.03.2017 um 10:29 schrieb Chris Wilson: >>> >>> On Tue, Mar 14, 2017 at 10:13:37AM +0100, Christian König wrote: >>>> >>>> Am 14.03.2017 um 09:45 schrieb Daniel Vetter: >>>>> >>>>> On Tue, Mar 14, 2017 at 10:50:51AM +1000, Dave Airlie wrote: >>>>>> >>>>>> From: Dave Airlie <airlied@xxxxxxxxxx> >>>>>> >>>>>> This isn't needed currently, but to reuse sync file for Vulkan >>>>>> permanent shared semaphore semantics, we need to be able to swap >>>>>> the fence backing a sync file. This patch adds a mutex to the >>>>>> sync file and uses to protect accesses to the fence and cb members. >>>>>> >>>>>> Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx> >>>>> >>>>> We've gone to pretty great lengths to rcu-protect all the fence stuff, >>>>> so >>>>> that a peek-only is entirely lockless. Can we haz the same for this pls? >>>> >>>> Yes, just wanted to suggest the same thing. >>>> >>>> Basically you just need the following to retrieve the fence: >>>> >>>> while (sync_file->fence && !(fence = fence_get_rcu(sync_file->fence)); >>> >>> We even have a helper for that: >>> >>> fence = dma_fence_get_rcu_safe(&sync_file->fence); >>> >>> (Still going to suggest using a reservation_object rather than an >>> exclusive-only implementation.) >> >> >> Yeah, thought about that as well. But the reservation object doesn't seem to >> match the required userspace semantic. >> >> E.g. you actually don't want more than one fence it in as far as I >> understand it. > > I don't think a reservation object is what the vulkan semantics ask for. > I suppose a reservation object with a single exclusive fence is close enough, just wouldn't want to create one with non-exclusive fences on it. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
