[PATCH 1/5] drm: introduce sync objects
Sean Paul
seanpaul at chromium.org
Tue May 9 14:56:51 UTC 2017
On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied at redhat.com>
>
> Sync objects are new toplevel drm object, that contain a
> pointer to a fence. This fence can be updated via command
> submission ioctls via drivers.
>
> There is also a generic wait obj API modelled on the vulkan
> wait API (with code modelled on some amdgpu code).
>
> These objects can be converted to an opaque fd that can be
> passes between processes.
>
> TODO: define sync_file interaction.
>
> Signed-off-by: Dave Airlie <airlied at redhat.com>
<snip>
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> new file mode 100644
> index 0000000..3cc42b7
> --- /dev/null
> +++ b/include/drm/drm_syncobj.h
<snip>
> +/**
> + * drm_gem_object_reference - acquire a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This acquires additional reference to @obj. It is illegal to call this
> + * without already holding a reference. No locks required.
> + */
> +static inline void
> +drm_syncobj_reference(struct drm_syncobj *obj)
> +{
> + kref_get(&obj->refcount);
> +}
> +
> +/**
> + * __drm_gem_object_unreference - raw function to release a GEM BO reference
> + * @obj: GEM buffer object
> + *
> + * This function is meant to be used by drivers which are not encumbered with
> + * &drm_device.struct_mutex legacy locking and which are using the
> + * gem_free_object_unlocked callback. It avoids all the locking checks and
> + * locking overhead of drm_gem_object_unreference() and
> + * drm_gem_object_unreference_unlocked().
> + *
> + * Drivers should never call this directly in their code. Instead they should
> + * wrap it up into a ``driver_gem_object_unreference(struct driver_gem_object
> + * *obj)`` wrapper function, and use that. Shared code should never call this, to
> + * avoid breaking drivers by accident which still depend upon
> + * &drm_device.struct_mutex locking.
Lot's of gem_obj copypasta to clean up in the comment here and above
> + */
> +static inline void
> +drm_syncobj_unreference(struct drm_syncobj *obj)
> +{
> + kref_put(&obj->refcount, drm_syncobj_free);
> +}
> +
> +int drm_syncobj_fence_get(struct drm_file *file_private,
> + u32 handle,
> + struct dma_fence **fence);
> +int drm_syncobj_replace_fence(struct drm_file *file_private,
> + u32 handle,
> + struct dma_fence *fence);
> +
> +#endif
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index b2c5284..dd0b99c 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -647,6 +647,7 @@ struct drm_gem_open {
> #define DRM_CAP_CURSOR_HEIGHT 0x9
> #define DRM_CAP_ADDFB2_MODIFIERS 0x10
> #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> +#define DRM_CAP_SYNCOBJ 0x13
>
> /** DRM_IOCTL_GET_CAP ioctl argument type */
> struct drm_get_cap {
> @@ -696,6 +697,25 @@ struct drm_prime_handle {
> __s32 fd;
> };
>
> +struct drm_syncobj_create {
> + __u32 handle;
> + __u32 flags;
> +};
> +
> +struct drm_syncobj_destroy {
> + __u32 handle;
> + __u32 pad;
> +};
> +
> +struct drm_syncobj_handle {
> + __u32 handle;
> + /** Flags.. only applicable for handle->fd */
> + __u32 flags;
> +
> + __s32 fd;
> + __u32 pad;
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
> @@ -814,6 +834,11 @@ extern "C" {
> #define DRM_IOCTL_MODE_CREATEPROPBLOB DRM_IOWR(0xBD, struct drm_mode_create_blob)
> #define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct drm_mode_destroy_blob)
>
> +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct drm_syncobj_create)
> +#define DRM_IOCTL_SYNCOBJ_DESTROY DRM_IOWR(0xC0, struct drm_syncobj_destroy)
> +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct drm_syncobj_handle)
> +
> /**
> * Device specific ioctls should only be in their respective headers
> * The device specific ioctl range is from 0x40 to 0x9f.
> --
> 2.9.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
More information about the amd-gfx
mailing list