All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.