On 4 August 2017 at 02:25, Chris Wilson chris@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).
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.
Userspace should be using different paths to get to these interfaces.
Dave.