[PATCH 1/5] drm: introduce sync objects

[Jason Ekstrand]

On Mon, May 8, 2017 at 7:26 PM, Dave Airlie <airlied at gmail.com> 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.
>
> >
> >> +static struct drm_syncobj *drm_syncobj_fdget(int fd)
> >
> > It will aslo be useful to export the fd -> syncobj function for drivers.
> In
> > the interface Jason has for execbuf, we can substitute the handle for an
> > fd + flag, which may be more convenient for the user.
>
> Happy once we have a use case for it, I'd rather we didn't expose the
> syncobj
> fd to userspace for anything but sending a syncobj between processes,
> avoiding
> using fd's is one of the main points of this, I'd hate for an API to
> demand we use
> fd's.
>

I'm not sure how useful Chris' use-case is here.  From a userspace
perspective, I don't want to burn any more FDs than I absolutely have to,
so I'll do the FD -> syncobj conversion on import and use the handle from
there on.  For sync_file, using the FD isn't a big deal as it's a one-shot
and we close it as soon as execbuf() is completed.  Permanently
exported/imported VkSemaphores, on the other hand, are re-usable long-lived
objects and the ioctl on import is a smal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170509/5e1608b9/attachment.html>