[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