[repost] drm sync objects cleaned up

[Chris Wilson]

On Wed, Apr 19, 2017 at 05:34:52AM +1000, Dave Airlie wrote:
> On 14 April 2017 at 19:45, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
> >> This set of sync object patches should address most of the issues
> >> raised in review.
> >>
> >> The major changes:
> >> Race on destroy should be gone,
> >> Documentation fixups
> >> amdgpu internal use p instead of adev fixups
> >>
> >> My plans are to write some igt tests this week, and try
> >> to get some more review on what the API should allow (should
> >> I lock it down to drm syncobj is just semaphores for now).
> >
> > Having an idr of handles is much, much nicer than fd and I want the same
> > for fences :)
> 
> Okay, but what form do you want the API to take for fences?
> 
> because I've just ported all this to using sem_file as the backend, instead
> of sync_file which seems to oppose the goal of using it for fences.
> 
> For fences do you want upfront creation, then passing created fences object
> into command submission that attach the internal fence?

Yes. My understanding is that fences differ from semaphores by allowing
use prior to execution. And that userspace (Vk) wants to be able to
create a fence, pass it to a listener (maybe different process) and then
attach it to an out-fence from a CS.

I looked at using a shared idr for fences/semaphores and the issue I hit
first was having to create a proxy dma-fence to initialise the syncobj
with, so that I could attach listeners before I was able to hook the
fence upto an execbuf.
 
> Or do you want command submission to have out fence handles that it creates,
> so we don't have any explicit syncobj create for fences?
> 
> Do you want those fences to be shareable across processes using sync_file
> semantics?

Yes. In the same vein as the semaphore syncobjs, an idr for cheap
creation/reuse within a process and export/import via sync_file fds.
Where these fd differ from sema is that they do support host CPU access
(these will work just like regular sync_files in that regard).
 
> I kinda feel like I'm going around in circles here and I'm going to just merge
> something instead.

Sure. It was just from the perspective of extending the i915 execbuffer2
that adding an array for semaphore in/out could be neatly generalised to
cover fences as well (and that the api for syncobj is a substantial
improvement over sync_merge and passing one fence in/out).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre