On Mon, May 8, 2017 at 7:26 PM, Dave Airlie <airlied@xxxxxxxxx> wrote:
On 4 May 2017 at 18:16, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 *file_private,
>> + 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 that
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. In
> 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 syncobj
fd to userspace for anything but sending a syncobj between processes, avoiding
using fd's is one of the main points of this, I'd hate for an API to
demand we use
fd's.
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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
