[Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

[Sagar Arun Kamble]

On 12/5/2017 8:07 PM, Lionel Landwerlin wrote:
> On 05/12/17 14:28, Robert Bragg wrote:
>>
>>
>> On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin 
>> <lionel.g.landwerlin at intel.com 
>> <mailto:lionel.g.landwerlin at intel.com>> wrote:
>>
>>     Hey Sagar,
>>
>>     Sorry for the delay looking into this series.
>>     I've done some userspace/UI work in GPUTop to try to correlate
>>     perf samples/tracepoints with i915 perf reports.
>>
>>     I wanted to avoid having to add too much logic into the kernel
>>     and tried to sample both cpu clocks & gpu timestamps from userspace.
>>     So far that's not working. People more knowledgable than I would
>>     have realized that the kernel can sneak in work into syscalls.
>>     So result is that 2 syscalls (one to get the cpu clock, one for
>>     the gpu timestamp) back to back from the same thread leads to
>>     time differences of anywhere from a few microseconds to in some
>>     cases close to 1millisecond. So it's basically unworkable.
>>     Anyway the UI work won't go to waste :)
>>
>>     I'm thinking to go with your approach.
>>     >From my experiment with gputop, it seems we might want to use a
>>     different cpu clock source though or make it configurable.
>>     The perf infrastructure allows you to choose what clock you want
>>     to use. Since we want to avoid time adjustments on that clock
>>     (because we're adding deltas), a clock monotonic raw would make
>>     most sense.
>>
>>
>> I would guess the most generally useful clock domain to correlate 
>> with the largest number of interesting events would surely be 
>> CLOCK_MONOTONIC, not _MONOTONIC_RAW.
>>
>> E.g. here's some discussion around why vblank events use 
>> CLOCK_MONOTINIC: 
>> https://lists.freedesktop.org/archives/dri-devel/2012-October/028878.html
>>
>> Br,
>> - Robert
>
> Thanks Rob, then I guess making it configurable when opening the 
> stream would be the safest option.
>
All timecounter users today rely on monotonic clock (Can request for clock real/wall time, clock boot time, clock tai time
corresponding to monotonic clock).
Agree that we will need to have configuration option about clock to be used like in trace_clock in ftrace.

>>
>>
>>     I'll look at adding some tests for this too.
>>
>>     Thanks,
>>
>>     -
>>     Lionel
>>
>>     On 15/11/17 12:13, Sagar Arun Kamble wrote:
>>
>>         We can compute system time corresponding to GPU timestamp by
>>         taking a
>>         reference point (CPU monotonic time, GPU timestamp) and then
>>         adding
>>         delta time computed using timecounter/cyclecounter support in
>>         kernel.
>>         We have to configure cyclecounter with the GPU timestamp
>>         frequency.
>>         Earlier approach that was based on cross-timestamp is not
>>         needed. It
>>         was being used to approximate the frequency based on invalid
>>         assumptions
>>         (possibly drift was being seen in the time due to precision
>>         issue).
>>         The precision of time from GPU clocks is already in ns and
>>         timecounter
>>         takes care of it as verified over variable durations.
>>
>>         This series adds base timecounter/cyclecounter changes and
>>         changes to
>>         get GPU and CPU timestamps in OA samples.
>>
>>         Sagar Arun Kamble (1):
>>            drm/i915/perf: Add support to correlate GPU timestamp with
>>         system time
>>
>>         Sourab Gupta (3):
>>            drm/i915/perf: Add support for collecting 64 bit
>>         timestamps with OA
>>              reports
>>            drm/i915/perf: Extract raw GPU timestamps from OA reports
>>            drm/i915/perf: Send system clock monotonic time in perf
>>         samples
>>
>>           drivers/gpu/drm/i915/i915_drv.h  |  11 ++++
>>           drivers/gpu/drm/i915/i915_perf.c | 124
>>         ++++++++++++++++++++++++++++++++++++++-
>>           drivers/gpu/drm/i915/i915_reg.h  |   6 ++
>>           include/uapi/drm/i915_drm.h      |  14 +++++
>>           4 files changed, 154 insertions(+), 1 deletion(-)
>>
>>
>>     _______________________________________________
>>     Intel-gfx mailing list
>>     Intel-gfx at lists.freedesktop.org
>>     <mailto:Intel-gfx at lists.freedesktop.org>
>>     https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>     <https://lists.freedesktop.org/mailman/listinfo/intel-gfx>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20171206/49fa269d/attachment-0001.html>