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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 16, 2018 at 5:06 PM Keith Packard <keithp@xxxxxxxxxx> wrote:
Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> 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?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux