[PATCH] vulkan: Add VK_EXT_calibrated_timestamps extension (radv and anv) [v4]

[Jason Ekstrand]

On Tue, Oct 16, 2018 at 5:06 PM Keith Packard <keithp at keithp.com> wrote:

> Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl> writes:
>
> > Well the complication here is that in the MONOTONIC (not
> > MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> > MONOTONIC_RAW interval (as the order of measurements is based on
> > argument order), so you can get a tick that started `period` (5 in
> > this case) monotonic ticks before the start of the interval and a CPU
> > measurement at the end of the interval.
>
> Ah, that's an excellent point. Let's split out raw and monotonic and
> take a look. You want the GPU sampled at the start of the raw interval
> and monotonic sampled at the end, I think?
>
>                  w x y z 0 1 2 3 4 5 6 7 8 9 a b c d e f
> Raw              -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>
>           0         1         2         3
> GPU       -----_____-----_____-----_____-----_____
>
>                                     x y z 0 1 2 3 4 5 6 7 8 9 a b c
> Monotonic                           -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>
> Interval                     <----------------->
> Deviation           <-------------------------->
>
>         start = read(raw)       2
>         gpu   = read(GPU)       1
>         mono  = read(monotonic) 2
>         end   = read(raw)       b
>
> In this case, the error between the monotonic pulse and the GPU is
> interval + gpu_period (probably plus one to include the measurement
> error of the raw clock).
>

I'm very confused by this case.  Why is monotonic timeline delayed?  It
seems to me like it's only the monotonic sampling that's delayed and the
result is that mono ends up closer to end than start so the sampled value
would be something like 9 or a rather than 2?

I think we can model this fairly simply as two components:

 1) The size of the sampling window; this is "end - start +
monotonic_raw_tick"
 2) The maximum phase shift of any sample.  The only issue here is that a
tick may have started before the sampling window so we need to add on the
maximum tick size.  The worst case bound for this is when the early sampled
clock is sampled at the end of a tick and the late sampled clock is sampled
at the beginning of a tick.

The result is that we're looking at something like "end - start +
monotonic_raw_tick + max(gpu_tick, monotonic_tick)"  Have I just come
full-circle?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20181016/c19cdaa2/attachment-0001.html>