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 deal. --Jason
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
