Quoting Dave Airlie (2017-08-04 00:01:10) > On 4 August 2017 at 02:25, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
