From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events
Date: Fri, 22 Dec 2017 10:45:50 +0530 [thread overview]
Message-ID: <d012ef27-c22b-c6d2-3d64-4848cb91afc6@intel.com> (raw)
In-Reply-To: <314be081-8216-9410-aefd-605d80beaf44@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 5273 bytes --]
On 12/7/2017 1:32 AM, Lionel Landwerlin wrote:
> I've put together some trival IGT tests :
> https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps
> With a few changes which I pointed in the review :
> https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d
>
> Put together it seems to work relatively well.
> There is still a small drift happening between the 2 timestamps. I've
> noticed over a 160ms of OA reports, there is a accumulated difference
> of ~35us between the GPU timestamp and cpu timestamps.
> I may be doing something wrong with the scaling in the tests, or maybe
> there is an issue in the kernel, or both.
Went through the testcase. scaled_gpu_delta calculation is same as what
timecounter does in kernel for calculating system_time corresponding
to gpu timestamp hence we don't see much of delta between these two
times/time deltas.
Ideally we should be testing the system time delta by sampling system
time and gpu timestamp atomically (which isn't feasible unless we do
some precise adjustments)
I have attempted to check these two times/delta by sampling them in
debugfs and reading over variable periods manually and checking the delta.
https://github.com/sakamble/i915-timestamp-support/commit/03be3056752d7b05a02cd01f5c20b3fcfcf18395
It is showing that delta is less than 10us in most cases for 30min and
occasionally around 20-30us. Again this delta might be because of
initial time setting as well.
timecounter initializing system time and gpu clocks as pair should be
highly accurate for which I have currently taken 350us start offset.
I think gpu timestamp clock is highly stable as seen in my testing on
SKL. I think this clock is used for calculations in GuC too so will
be good to get confirmation about the stability of this clock from them
and HW team.
systemd-udevd-169 [001] .... 3.035812: i915_driver_load: sys
start time: 1512308011156099790
systemd-udevd-169 [001] d... 3.036012: i915_cyclecounter_read:
52025098974
cat-1654 [001] .... 52.407957: i915_cyclecounter_read:
52617562292
cat-1654 [001] .... 52.407958: i915_timestamp_info:
sys time: 1512308060527894638
cat-1654 [001] .... 52.407958: i915_timestamp_info:
ts: 52617562292 device time: 1512308060528043050
cat-1684 [001] .... 177.239733: i915_cyclecounter_read:
54115543581
cat-1684 [001] .... 177.239736: i915_timestamp_info:
sys time: 1512308185359666602
cat-1684 [001] .... 177.239737: i915_timestamp_info:
ts: 54115543581 device time: 1512308185359817372
cat-1693 [001] .... 329.820374: i915_cyclecounter_read:
55946511277
cat-1693 [001] .... 329.820377: i915_timestamp_info:
sys time: 1512308337940301732
cat-1693 [001] .... 329.820378: i915_timestamp_info:
ts: 55946511277 device time: 1512308337940458996
<delta between system time delta and gpu time delta for above two
samples (177, 329) = 6494ns>
cat-1702 [001] .... 506.980313: i915_cyclecounter_read:
58072430542
cat-1702 [001] .... 506.980315: i915_timestamp_info:
sys time: 1512308515100233102
cat-1702 [001] .... 506.980317: i915_timestamp_info:
ts: 58072430542 device time: 1512308515100398084
<delta between system time delta and gpu time delta for above two
samples (329, 506) = 6494ns>
>
> I'll build the GPUTop parts and see if the results make sense.
>
> 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(-)
>>
>
[-- Attachment #1.2: Type: text/html, Size: 7586 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-22 5:15 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
2017-12-06 9:01 ` Sagar Arun Kamble
2017-12-06 20:02 ` Lionel Landwerlin
2017-12-22 5:15 ` Sagar Arun Kamble [this message]
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=d012ef27-c22b-c6d2-3d64-4848cb91afc6@intel.com \
--to=sagar.a.kamble@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lionel.g.landwerlin@intel.com \
/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.