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