[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Jason Ekstrand]

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

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > Is the given sequence number guaranteed to be hit in finite time?
>
> Certainly, it's a finite value...
>
> However, realistically, it's just like all of the other vblank
> interfaces where you can specify a crazy sequence and block for a very
> long time. So, no different from the current situation.
>
> Of course, the only vulkan API available today only lets you wait for
> the next vblank, so we'll be asking for a sequence which is one more
> than the current sequence.
>
> > 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 it cares, it can ask. It might not care at all, in which case it
> wouldn't have to ask. The syncobj API doesn't provide any direct
> information about the state of the object in the wait call.
>

Yeah, I suppose an application could ask for 10k frames in the future or
something ridiculous like that.  For sync_file, people strongly want a
finite time guarantee for security/deadlock reasons.  I don't know how
happy they would be with a finite time of 10 minutes...


> > If so, what happens if a syncobj is re-used?  Do you just loose the
> > information?
>
> You can't reuse one of these -- the 'queue_syncobj' API creates a new
> one each time.
>

Ok, that's not expected... Part of the point of sync objects is that
they're re-usable.  The client is free to not re-use them or to be very
careful about the recycling process.


> > 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.
>
> It's a one-shot, once signaled, you're done with it.
>
> > This whole "wait for a syncobj and then ask when it fired" thing is a bit
> > odd.  I'll have to think on it.
>
> Yeah, the event mechanism has the nice feature that you get data with
> each event. I guess the alternative would be to have a way to get an
> event when a sync object was ready; perhaps a call which provided a set
> of syncobjs and delivered a DRM event when any of them was ready?
>
> That has a lot of appeal; it turns the poll-like nature of the current
> API into an epoll-like system. Hrm.
>

Is the event the important part or the moderately accurate timestamp?  We
could probably modify drm_syncobj to have a "last signaled" timestamp
that's queryable through an IOCTL.

Is the sequence number returned necessary?  Will it ever be different from
the one requested?

Sorry, lots of questions.  KMS isn't a domain about which I know a great
deal.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180406/ed8595ff/attachment.html>