[rfc] amdgpu/sync_file shared semaphores

[Daniel Vetter]

On Wed, Mar 15, 2017 at 11:09:39AM +1000, Dave Airlie wrote:
> 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!

Yeah, vgem semaphore replacement ioctl is what I had in mind. And I guess
if you don't get around to it, we will when we do the i915 side of this
:-)
-Daniel

> 
> >
> > 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.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch