[PATCH 1/5] drm: introduce sync objects

[Chris Wilson]

On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote:
> On 4 May 2017 at 18:16, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include <drm/drmP.h>
> >
> > I wonder if Daniel has already split everything used here into its own
> > headers?
> 
> not sure, if drm_file is out there yet. I'll find out when I rebase
> this onto something newer I expect.
> >> +
> >> +static struct drm_syncobj *drm_syncobj_get(struct drm_file *file_private,
> >> +                                        u32 handle)
> >
> > I would like this exposed to the driver as well, so I can do handle to
> > syncobj conversion once. (drm_syncobj_find() if we go with kref_get style
> > naming.)
> 
> Where do you expect to need two lookups? At least for the semaphore APIs,
> you have a list of wait and list of signals, the lists should be different, I've
> no objections to exporting this later, but it would be easier to just do that
> with the first user.

i915 being a laggard with an inflexible ioctl struct, we've repurposed a
single array to hold both in/out. From the kernel point of view we have
a handle + a flag to wait/signal/unsignal. In the first pass we add the
waits, in the second pass we clear in-semaphores, signal out-semaphores.
Userspace is able to express its requirements as a set of operations -
I was looking at reusing this api for fence handling as well. The
difference being that we didn't want to clear the in-fences after
waiting.

So i915, one array of mixed in/out, 2 passes (before/after submit).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre