From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
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: Wed, 6 Dec 2017 14:31:05 +0530 [thread overview]
Message-ID: <3657dbcc-b3b8-b23c-a6ba-4c8282d7832c@intel.com> (raw)
In-Reply-To: <426e5216-4346-ba17-f220-56ac8ad3409e@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 4441 bytes --]
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@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.
>
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@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: 8404 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
next prev parent reply other threads:[~2017-12-06 9:01 UTC|newest]
Thread overview: 35+ 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-12-05 13:58 ` 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
2017-12-06 9:01 ` Sagar Arun Kamble [this message]
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=3657dbcc-b3b8-b23c-a6ba-4c8282d7832c@intel.com \
--to=sagar.a.kamble@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lionel.g.landwerlin@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox