[PATCH 1/4] sync_file: add a mutex to protect fence and callback members.

[Dave Airlie]

On 15 March 2017 at 10:47, Dave Airlie <airlied at gmail.com> wrote:
> On 14 March 2017 at 19:30, Christian König <deathsimple at vodafone.de> 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 at redhat.com>
>>>>>>
>>>>>> 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 at redhat.com>
>>>>>
>>>>> 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.