<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 6, 2018 at 7:51 PM, Keith Packard <span dir="ltr"><<a href="mailto:keithp@keithp.com" target="_blank">keithp@keithp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> Is the given sequence number guaranteed to be hit in finite time?<br>
<br>
</span>Certainly, it's a finite value...<br>
<br>
However, realistically, it's just like all of the other vblank<br>
interfaces where you can specify a crazy sequence and block for a very<br>
long time. So, no different from the current situation.<br>
<br>
Of course, the only vulkan API available today only lets you wait for<br>
the next vblank, so we'll be asking for a sequence which is one more<br>
than the current sequence.<br>
<span class=""><br>
> Just to make sure I've got this straight, the client queues a syncobj with<br>
> queue_syncobj to fire at a given sequence number.  Once the syncobj has<br>
> fired (which it can find out by waiting on it), it then calls get_syncobj<br>
> to figure out when it was fired?<br>
<br>
</span>If it cares, it can ask. It might not care at all, in which case it<br>
wouldn't have to ask. The syncobj API doesn't provide any direct<br>
information about the state of the object in the wait call.<span class=""><br></span></blockquote><div><br></div><div>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...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> If so, what happens if a syncobj is re-used?  Do you just loose the<br>
> information?<br>
<br>
</span>You can't reuse one of these -- the 'queue_syncobj' API creates a new<br>
one each time.<span class=""><br></span></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> If we have a finite time guarantee, I'm kind-of thinking a sync_file might<br>
> be better as it's a one-shot and doesn't have the information loss<br>
> problem.  I'm not actually sure though.<br>
<br>
</span>It's a one-shot, once signaled, you're done with it.<br>
<span class=""><br>
> This whole "wait for a syncobj and then ask when it fired" thing is a bit<br>
> odd.  I'll have to think on it.<br>
<br>
</span>Yeah, the event mechanism has the nice feature that you get data with<br>
each event. I guess the alternative would be to have a way to get an<br>
event when a sync object was ready; perhaps a call which provided a set<br>
of syncobjs and delivered a DRM event when any of them was ready?<br>
<br>
That has a lot of appeal; it turns the poll-like nature of the current<br>
API into an epoll-like system. Hrm.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Is the sequence number returned necessary?  Will it ever be different from the one requested?<br><br></div><div class="gmail_extra">Sorry, lots of questions.  KMS isn't a domain about which I know a great deal.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">--Jason<br></div></div>