[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

Jason Ekstrand jason at jlekstrand.net
Sat Apr 7 00:09:33 UTC 2018


On Fri, Apr 6, 2018 at 4:56 PM, Keith Packard <keithp at keithp.com> wrote:

> crtc_queue_syncobj creates a new syncobj that will get signaled at a
> specified vblank sequence count.
>
> crtc_get_syncobj returns the time and vblank sequence count when the
> syncobj was signaled.
>
> The pair of these allows use of syncobjs instead of events for
> monitoring vblank activity.
>
> Signed-off-by: Keith Packard <keithp at keithp.com>
> ---
>  drivers/gpu/drm/drm_file.c     |   5 +
>  drivers/gpu/drm/drm_internal.h |   4 +
>  drivers/gpu/drm/drm_ioctl.c    |   2 +
>  drivers/gpu/drm/drm_syncobj.c  |  13 ++-
>  drivers/gpu/drm/drm_vblank.c   | 212 ++++++++++++++++++++++++++++++
> +++++++----
>  include/drm/drm_file.h         |  11 ++-
>  include/drm/drm_syncobj.h      |  13 +++
>  include/uapi/drm/drm.h         |  17 ++++
>  8 files changed, 253 insertions(+), 24 deletions(-)
>

[...]


> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 6fdff5945c8a..7a996f73e972 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -759,6 +759,21 @@ struct drm_crtc_queue_sequence {
>         __u64 user_data;        /* user data passed to event */
>  };
>
> +struct drm_crtc_queue_syncobj {
> +       __u32 crtc_id;
> +       __u32 flags;
> +       __u64 sequence;
>

Is the given sequence number guaranteed to be hit in finite time?


> +       __u32 handle;           /* return syncobj handle */
> +       __u32 pad;
> +};
> +
> +struct drm_crtc_get_syncobj {
> +       __u32 handle;           /* signaled syncobj */
> +       __u32 pad;
> +       __u64 sequence;         /* return: sequence when syncobj was
> signaled */
> +       __u64 sequence_ns;      /* return: time when syncobj was signaled
> */
>

Just to make sure I've got this straight, the client queues a syncobj with
queue_syncobj to fire at a given sequence number.  Once the syncobj has
fired (which it can find out by waiting on it), it then calls get_syncobj
to figure out when it was fired?

If so, what happens if a syncobj is re-used?  Do you just loose the
information?

If we have a finite time guarantee, I'm kind-of thinking a sync_file might
be better as it's a one-shot and doesn't have the information loss
problem.  I'm not actually sure though.

This whole "wait for a syncobj and then ask when it fired" thing is a bit
odd.  I'll have to think on it.

--Jason


> +};
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> @@ -843,6 +858,8 @@ extern "C" {
>
>  #define DRM_IOCTL_CRTC_GET_SEQUENCE    DRM_IOWR(0x3b, struct
> drm_crtc_get_sequence)
>  #define DRM_IOCTL_CRTC_QUEUE_SEQUENCE  DRM_IOWR(0x3c, struct
> drm_crtc_queue_sequence)
> +#define DRM_IOCTL_CRTC_QUEUE_SYNCOBJ   DRM_IOWR(0x3d, struct
> drm_crtc_queue_syncobj)
> +#define DRM_IOCTL_CRTC_GET_SYNCOBJ     DRM_IOWR(0x3e, struct
> drm_crtc_get_syncobj)
>
>  #define DRM_IOCTL_UPDATE_DRAW          DRM_IOW(0x3f, struct
> drm_update_draw)
>
> --
> 2.16.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180406/0c93925b/attachment.html>


More information about the dri-devel mailing list