[rfc] amdgpu/sync_file shared semaphores

[Dave Airlie]

On 14 March 2017 at 18:53, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, Mar 14, 2017 at 10:50:49AM +1000, Dave Airlie wrote:
>> This contains one libdrm patch and 4 kernel patches.
>>
>> The goal is to implement the Vulkan KHR_external_semaphore_fd interface
>> for permanent semaphore behaviour for radv.
>>
>> This code tries to enhance sync file to add the required behaviour
>> (which is mostly being able to replace the fence backing the sync file),
>> it also introduces new API to amdgpu to create/destroy/export/import the
>> sync_files which we store in an idr there, rather than fds.
>>
>> There is a possibility we should share the amdgpu_sem object tracking
>> code for other drivers, maybe we should move that to sync_file as well,
>> but I'm open to suggestions for whether this is a useful approach for
>> other drivers.
>
> Yeah, makes sense. I couldn't google the spec and didn't bother to figure
> out where my intel khronos login went, so didn't double-check precise
> semantics, just dropped a question. Few more things on the actual
> sync_file stuff itself.
>
> Really big wish here is for some igts using the debug/testing fence stuff
> we have in vgem so that we can validate the corner-cases of fence
> replacement and make sure nothing falls over. Especially with all the rcu
> dancing sync_file/dma_fence have become non-trival, exhaustive testing is
> needed here imo.

We'd have to add vgem specific interfaces to trigger the replacement
path though,
since the replacement path is only going to be used for the semaphore sematics.

Suggestions on how to test better welcome!

>
> Also, NULL sync_file->fence is probably what we want for the future fences
> (which android wants to keep tilers well-fed by essentially looping the
> entire render pipeline on itself), so this goes into the right direction
> for sure. I think, but coffee kicked in already :-)

Dave.