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
