On Wed, Oct 17, 2018 at 12:14 AM Keith Packard wrote:
> Jason Ekstrand writes:
>
> > Doing all of the CPU sampling on one side or the other of the GPU
> sampling
> > would probably reduce our window.
>
> True, although as I said, it's taking several µs to get through the
> loop, and the gpu
Jason Ekstrand writes:
> Doing all of the CPU sampling on one side or the other of the GPU sampling
> would probably reduce our window.
True, although as I said, it's taking several µs to get through the
loop, and the gpu clock tick is far smaller than that, so even adding
the two values
Jason Ekstrand writes:
> 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?
Yes. As monotonic_raw_tick and monotonic_tick are both 1...
--
-keith
signature.asc
Description: PGP signature
On Tue, Oct 16, 2018 at 5:56 PM Keith Packard wrote:
> Bas Nieuwenhuizen writes:
>
> > You can make the monotonic case the same as the raw case if you make
> > sure to always sample the CPU first by e.g. splitting the loops into
> > two and doing CPU in the first and GPU in the second. That way
On Tue, Oct 16, 2018 at 5:06 PM Keith Packard wrote:
> Bas Nieuwenhuizen 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
> >
Bas Nieuwenhuizen writes:
> You can make the monotonic case the same as the raw case if you make
> sure to always sample the CPU first by e.g. splitting the loops into
> two and doing CPU in the first and GPU in the second. That way you
> make the case above impossible.
Right, I had thought of
On Wed, Oct 17, 2018 at 12:06 AM Keith Packard wrote:
>
> Bas Nieuwenhuizen 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
> >
Bas Nieuwenhuizen 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
>
Jason Ekstrand writes:
> You've got me almost convinced as well. Thanks for the diagrams! I think
> instead of adding 1 perhaps what we want is
>
> max2(sample_interval_ns, gpu_tick_ns + monotonic_tick_ns)
>
> Where monotonic_tick_ns is maybe as low as 1. Am I following you correctly?
Not
On Tue, Oct 16, 2018 at 11:07 PM Keith Packard wrote:
>
> Jason Ekstrand writes:
>
> > I think what Bas is getting at is that there are two problems:
> >
> > 1) We are not sampling at exactly the same time
> > 2) The two clocks may not tick at exactly the same time.
>
> Thanks for the
On Tue, Oct 16, 2018 at 4:07 PM Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I think what Bas is getting at is that there are two problems:
> >
> > 1) We are not sampling at exactly the same time
> > 2) The two clocks may not tick at exactly the same time.
>
> Thanks for the
Jason Ekstrand writes:
> I think what Bas is getting at is that there are two problems:
>
> 1) We are not sampling at exactly the same time
> 2) The two clocks may not tick at exactly the same time.
Thanks for the clarification.
> If we want to be conservative, I suspect Bas may be right
On Tue, Oct 16, 2018 at 2:35 PM Keith Packard wrote:
> Bas Nieuwenhuizen writes:
>
> >> + end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
> >> +
> >> + uint64_t clock_period = end - begin;
> >> + uint64_t device_period = DIV_ROUND_UP(100,
> clock_crystal_freq);
> >> +
> >>
Bas Nieuwenhuizen writes:
>> + end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
>> +
>> + uint64_t clock_period = end - begin;
>> + uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
>> +
>> + *pMaxDeviation = MAX2(clock_period, device_period);
>
> Should
On Tue, Oct 16, 2018 at 7:31 AM Keith Packard wrote:
>
> Offers three clocks, device, clock monotonic and clock monotonic
> raw. Could use some kernel support to reduce the deviation between
> clock values.
>
> v2:
> Ensure deviation is at least as big as the GPU time interval.
>
> v3:
>
The RADV bits are:
Reviewed-by: Samuel Pitoiset
Thanks!
On 10/16/18 7:31 AM, Keith Packard wrote:
Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.
v2:
Ensure deviation is at least as big
16 matches
Mail list logo
