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. > 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. > 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. -- -keith
Description: PGP signature