[PATCH 1/5] drm: introduce sync objects
jason at jlekstrand.net
Tue May 9 22:06:42 UTC 2017
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
> >> + 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
> 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.
> > 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
> fd to userspace for anything but sending a syncobj between processes,
> using fd's is one of the main points of this, I'd hate for an API to
> demand we use
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...
More information about the amd-gfx