[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