All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Robert Bragg <robert@sixbynine.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events
Date: Tue, 5 Dec 2017 14:37:47 +0000	[thread overview]
Message-ID: <426e5216-4346-ba17-f220-56ac8ad3409e@intel.com> (raw)
In-Reply-To: <CAMou1-0j1XG2dpDyUOmdfeW_WN3Om89ALh=X-z2vyY7midd-OA@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4004 bytes --]

On 05/12/17 14:28, Robert Bragg wrote:
>
>
> On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin 
> <lionel.g.landwerlin@intel.com <mailto:lionel.g.landwerlin@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.

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


[-- Attachment #1.2: Type: text/html, Size: 7437 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

  reply	other threads:[~2017-12-05 14:37 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 12:13 [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events Sagar Arun Kamble
2017-11-15 12:13 ` [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time Sagar Arun Kamble
2017-11-15 12:25   ` Chris Wilson
2017-11-15 16:41     ` Sagar Arun Kamble
2017-11-23  7:34     ` Creating cyclecounter and lock member in timecounter structure [ Was Re: [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time] Sagar Arun Kamble
2017-11-23 18:59       ` Thomas Gleixner
2017-11-24  9:06         ` Sagar Arun Kamble
2017-11-24 13:31           ` Thomas Gleixner
2017-11-27 10:05             ` Sagar Arun Kamble
2017-11-27 10:05               ` Sagar Arun Kamble
     [not found]               ` <63a2a495-1bdb-5d47-1202-9b538e9601d8-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-11-30 21:03                 ` Saeed Mahameed
2017-11-30 21:03                   ` Saeed Mahameed
     [not found]                   ` <CALzJLG9JXOnr3EQ2zLcmwKx8S9-CGONRRBSAd9XwHdemEgOn2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-01  7:42                     ` Sagar Arun Kamble
2017-12-01  7:42                       ` Sagar Arun Kamble
2017-12-05 13:58     ` [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time Lionel Landwerlin
2017-12-06  8:17       ` Sagar Arun Kamble
2017-11-15 12:13 ` [RFC 2/4] drm/i915/perf: Add support for collecting 64 bit timestamps with OA reports Sagar Arun Kamble
2017-12-06 16:01   ` Lionel Landwerlin
2017-12-21  8:38     ` Sagar Arun Kamble
2017-11-15 12:13 ` [RFC 3/4] drm/i915/perf: Extract raw GPU timestamps from " Sagar Arun Kamble
2017-12-06 19:55   ` Lionel Landwerlin
2017-12-21  8:50     ` Sagar Arun Kamble
2017-11-15 12:13 ` [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples Sagar Arun Kamble
2017-11-15 12:31   ` Chris Wilson
2017-11-15 16:51     ` Sagar Arun Kamble
2017-11-15 17:54   ` Sagar Arun Kamble
2017-12-05 14:22   ` Lionel Landwerlin
2017-12-06  8:31     ` Sagar Arun Kamble
2017-11-15 12:30 ` ✗ Fi.CI.BAT: warning for GPU/CPU timestamps correlation for relating OA samples with system events Patchwork
2017-12-05 14:16 ` [RFC 0/4] " Lionel Landwerlin
2017-12-05 14:28   ` Robert Bragg
2017-12-05 14:37     ` Lionel Landwerlin [this message]
2017-12-06  9:01       ` Sagar Arun Kamble
2017-12-06 20:02 ` Lionel Landwerlin
2017-12-22  5:15   ` Sagar Arun Kamble
2017-12-22  5:26     ` Sagar Arun Kamble
2017-12-07  0:48 ` Robert Bragg
2017-12-07  0:57   ` Robert Bragg
2017-12-21 12:59     ` Lionel Landwerlin
2017-12-22  9:30       ` Sagar Arun Kamble
2017-12-22 10:16         ` Lionel Landwerlin
2017-12-26  5:32           ` Sagar Arun Kamble
2017-12-28 17:13             ` Lionel Landwerlin
2018-01-03  5:38               ` Sagar Arun Kamble
2017-12-22  6:06   ` Sagar Arun Kamble

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426e5216-4346-ba17-f220-56ac8ad3409e@intel.com \
    --to=lionel.g.landwerlin@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=robert@sixbynine.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.