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: 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox