On Fri, Apr 6, 2018 at 7:51 PM, Keith Packard <keithp@xxxxxxxxxx> wrote:
Jason Ekstrand <jason@xxxxxxxxxxxxxx> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
