[PATCH 3/5] drm/syncobj: add sync_file interaction.

[Chris Wilson]

Quoting Dave Airlie (2017-08-04 00:01:10)
> On 4 August 2017 at 02:25, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > Quoting Dave Airlie (2017-05-12 01:34:55)
> >> @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> >>         if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
> >>                 return -ENODEV;
> >>
> >> +       if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE_FENCE)
> >> +               return drm_syncobj_import_sync_file_fence(file_private,
> >> +                                                         args->fd,
> >> +                                                         args->handle);
> >> +       else if (args->flags)
> >> +               return -EINVAL;
> >
> > Argh, what I missed before was that importing from a sync_file reuses
> > the handle, but importing from a syncobj fd creates a new handle.
> >
> > Just venting my ocd. It would be nice if the interface was consistent,
> > and I can see arguments for both approaches (just not a good argument as
> > to why they should differ). A compromise would be a flag to create/reuse
> > handle (or if handle=0, create, if handle!=0 resuse).
> 
> The interface is consistent for the objects.
> 
> With a sync_fd import you import the state into an existing syncobj.
> 
> With a syncobj import you import the object into the current process state
> (so get a new handle).

You can say the same for either path though, e.g.

With a sync fd import you import the fence into the current process state
(so get a new handle).

One process is using explict sync file fencing, presumably passing it to
kms and other consumers,and passes it to a second process that prefers to
use syncobj and so encapsulates it.
 
> I can't think of a use case for anything else, maybe having a sync_fd state
> imported into a new syncobj? but not sure it really helps.

Yes, I expect taking a sync_file fd and generating a new syncobj is just
as desired as taking a syncobj fd and generating a new synbocj.
Conversely, importing a syncobj fd into a preallocated syncobj makes
just as much sense as for a sync_file fd.
 
> Userspace should be using different paths to get to these interfaces.

Still the interfaces are different for no good reason, which certainly
makes for a surprising API.
-Chris