<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 12:14 AM Keith Packard <<a href="mailto:keithp@keithp.com">keithp@keithp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
<br>
> Doing all of the CPU sampling on one side or the other of the GPU sampling<br>
> would probably reduce our window.<br>
<br>
True, although as I said, it's taking several µs to get through the<br>
loop, and the gpu clock tick is far smaller than that, so even adding<br>
the two values together to make it fit the current implementation won't<br>
make the deviation that much larger.<br>
<br>
> This leaves us with a delta of I + max(P(M), P(R), P(G)).  In<br>
> particular, any two real-number valued times are, instantaneously,<br>
> within that interval.<br>
<br>
That, at least, would be easy to compute, and scale nicely if we added<br>
more clocks in the future.<br>
<br>
> Personally, I'm completely content to have the delta just be a the first<br>
> one: a bound on the difference between any two real-valued times.  At this<br>
> point, I can guarantee you that far more thought has been put into this<br>
> mesa-dev discussion than was put into the spec and I think we're rapidly<br>
> getting to the point of diminishing returns. :-)<br>
<br>
It seems likely. How about we do the above computation for the current<br>
code and leave it at that?<br></blockquote><div><br></div><div>Sounds like a plan.  Note that I should be computed as I = end - start + monotonic_raw_tick_ns to ensure we get a big enough interval.  Given that monotonic_raw_tick_ns is likely 1, this doesn't expand things much.</div><div><br></div><div>I think a comment is likely also in order.  Probably not containing the entire e-mail thread but maybe some of my reasoning above?</div><div><br></div><div>--Jason<br></div></div></div>