On 25 May 2017 at 18:30, Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote:
From: Dave Airlie airlied@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.
v2: rename reference/unreference to put/get (Chris) fix leaked reference (David Zhou) drop mutex in favour of cmpxchg (Chris) v3: cleanups from danvet, rebase on drm_fops rename check fd_flags is 0 in ioctls.
Reviewed-by: Sean Paul seanpaul@chromium.org Signed-off-by: Dave Airlie airlied@redhat.com
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 42d9f64..96c5c78 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -648,6 +648,7 @@ struct drm_gem_open { #define DRM_CAP_ADDFB2_MODIFIERS 0x10 #define DRM_CAP_PAGE_FLIP_TARGET 0x11 #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12 +#define DRM_CAP_SYNCOBJ 0x13
/** DRM_IOCTL_GET_CAP ioctl argument type */ struct drm_get_cap { @@ -697,6 +698,24 @@ 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;__u32 flags;__s32 fd;__u32 pad;+};
#if defined(__cplusplus) } #endif @@ -815,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)
These two only need DRM_IOW.
They do now, but at least create takes some flags, destroy is probably fine. are we okay to change these flags later?
I can never remember and I'd rather not have to think about it too much.
With that, Reviewed-by: Chris Wilson chris@chris-wilson.co.uk
Thanks, Dave.