Re: [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

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

 



On 05/12/17 14:28, Robert Bragg wrote:


On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> 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.



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@xxxxxxxxxxxxxxxxxxxxg
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux