<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018 at 2:35 PM 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">Bas Nieuwenhuizen <<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank">bas@basnieuwenhuizen.nl</a>> writes:<br>
<br>
>> +       end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);<br>
>> +<br>
>> +       uint64_t clock_period = end - begin;<br>
>> +       uint64_t device_period = DIV_ROUND_UP(1000000, clock_crystal_freq);<br>
>> +<br>
>> +       *pMaxDeviation = MAX2(clock_period, device_period);<br>
><br>
> Should this not be a sum? Those deviations can happen independently<br>
> from each other, so worst case both deviations happen in the same<br>
> direction which causes the magnitude to be combined.<br>
<br>
This use of MAX2 comes right from one of the issues raised during work<br>
on the extension:<br>
<br>
 8) Can the maximum deviation reported ever be zero?<br>
<br>
 RESOLVED: Unless the tick of each clock corresponding to the set of<br>
 time domains coincides and all clocks can literally be sampled<br>
 simutaneously, there isn’t really a possibility for the maximum<br>
 deviation to be zero, so by convention the maximum deviation is always<br>
 at least the maximum of the length of the ticks of the set of time<br>
 domains calibrated and thus can never be zero.<br>
<br>
I can't wrap my brain around this entirely, but I think that this says<br>
that the deviation reported is supposed to only reflect the fact that we<br>
aren't sampling the clocks at the same time, and so there may be a<br>
'tick' of error for any sampled clock.<br>
<br>
If you look at the previous issue in the spec, that actually has the<br>
pseudo code I used in this implementation for computing maxDeviation<br>
which doesn't include anything about the time period of the GPU.<br>
<br>
Jason suggested using the GPU period as the minimum value for<br>
maxDeviation at the GPU time period to make sure we never accidentally<br>
returned zero, as that is forbidden by the spec. We might be able to use<br>
1 instead, but it won't matter in practice as the time it takes to<br>
actually sample all of the clocks is far longer than a GPU tick.<br></blockquote><div><br></div><div>I think what Bas is getting at is that there are two problems:</div><div><br></div><div> 1) We are not sampling at exactly the same time</div><div> 2) The two clocks may not tick at exactly the same time.</div><div><br></div><div>Even if I can simultaneously sample the CPU and GPU clocks, their oscilators are not aligned and I my sample may be at the begining of the CPU tick and the end of the GPU tick.  If I had sampled 75ns earlier, I could have gotten lower CPU time but the same GPU time (most intel GPUs have about an 80ns tick).</div><div><br></div><div>If we want to be conservative, I suspect Bas may be right that adding is the safer thing to do.</div><div><br></div><div>--Jason<br></div></div></div>