Re: [rfc] amdgpu/sync_file shared semaphores

From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
To: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	amd-gfx mailing list
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Subject: Re: [rfc] amdgpu/sync_file shared semaphores
Date: Wed, 15 Mar 2017 09:47:04 +0100	[thread overview]
Message-ID: <20170315084704.3sf2amko7ld47aqh@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9txSFTkz0y5hamBA7U7fu+X8x_wHG+X3xtWvm2PY4aCwsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Mar 15, 2017 at 11:09:39AM +1000, Dave Airlie wrote:
> On 14 March 2017 at 18:53, Daniel Vetter <daniel@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
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx