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

> Jason Ekstrand <ja...@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

dri-devel mailing list

Reply via email to