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

[Dave Airlie]

On 4 August 2017 at 09:22, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 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).

You import the fence, not the sync_fd. There is a difference here. A syncobj
has a fence underlying it, it makes sense to import a new fence state into
an existing object. It doesn't make sense to import a new syncobj into an
existing object. It would be like importing a GEM object into a GEM object.

I expect document it and be done is the best answer unless we can come up
with a userspace use case that really expects the other behaviour.

Dave.