From: Sagar Arun Kamble <sagar.a.kamble@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Sourab Gupta <sourab.gupta@intel.com>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples
Date: Wed, 15 Nov 2017 23:24:09 +0530 [thread overview]
Message-ID: <e7216086-96a1-d07e-f305-caa839399c8d@intel.com> (raw)
In-Reply-To: <1510748034-14034-5-git-send-email-sagar.a.kamble@intel.com>
On 11/15/2017 5:43 PM, Sagar Arun Kamble wrote:
> From: Sourab Gupta <sourab.gupta@intel.com>
>
> Currently, we have the ability to only forward the GPU timestamps in the
> samples (which are generated via OA reports). This limits the ability to
> correlate these samples with the system events.
>
> An ability is therefore needed to report timestamps in different clock
> domains, such as CLOCK_MONOTONIC, in the perf samples to be of more
> practical use to the userspace. This ability becomes important
> when we want to correlate/plot GPU events/samples with other system events
> on the same timeline (e.g. vblank events, or timestamps when work was
> submitted to kernel, etc.)
>
> The patch here proposes a mechanism to achieve this. The correlation
> between gpu time and system time is established using the timestamp clock
> associated with the command stream, abstracted as timecounter/cyclecounter
> to retrieve gpu/system time correlated values.
>
> v2: Added i915_driver_init_late() function to capture the new late init
> phase for perf (Chris)
>
> v3: Removed cross-timestamp changes.
>
> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Sourab Gupta <sourab.gupta@intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> ---
> drivers/gpu/drm/i915/i915_perf.c | 27 +++++++++++++++++++++++++++
> include/uapi/drm/i915_drm.h | 7 +++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
> index 3b721d7..94ee924 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -336,6 +336,7 @@
>
> #define SAMPLE_OA_REPORT BIT(0)
> #define SAMPLE_GPU_TS BIT(1)
> +#define SAMPLE_SYSTEM_TS BIT(2)
>
> /**
> * struct perf_open_properties - for validated properties given to open a stream
> @@ -622,6 +623,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
> struct drm_i915_perf_record_header header;
> u32 sample_flags = stream->sample_flags;
> u64 gpu_ts = 0;
> + u64 system_ts = 0;
>
> header.type = DRM_I915_PERF_RECORD_SAMPLE;
> header.pad = 0;
> @@ -647,6 +649,23 @@ static int append_oa_sample(struct i915_perf_stream *stream,
>
> if (copy_to_user(buf, &gpu_ts, I915_PERF_TS_SAMPLE_SIZE))
> return -EFAULT;
> + buf += I915_PERF_TS_SAMPLE_SIZE;
> + }
> +
> + if (sample_flags & SAMPLE_SYSTEM_TS) {
> + gpu_ts = get_gpu_ts_from_oa_report(stream, report);
> + /*
> + * XXX: timecounter_cyc2time considers time backwards if delta
> + * timestamp is more than half the max ns time covered by
> + * counter. It will be ~35min for 36 bit counter. If this much
> + * sampling duration is needed we will have to update tc->nsec
> + * by explicitly reading the timecounter (timecounter_read)
> + * before this duration.
This is implemented as overflow watchdog in mlx5e_timestamp_init
(drivers/net/ethernet/mellanox).
Will need similar mechanism here.
> + */
> + system_ts = timecounter_cyc2time(&stream->tc, gpu_ts);
> +
> + if (copy_to_user(buf, &system_ts, I915_PERF_TS_SAMPLE_SIZE))
> + return -EFAULT;
> }
>
> (*offset) += header.size;
> @@ -2137,6 +2156,11 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
> stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
> }
>
> + if (props->sample_flags & SAMPLE_SYSTEM_TS) {
> + stream->sample_flags |= SAMPLE_SYSTEM_TS;
> + stream->sample_size += I915_PERF_TS_SAMPLE_SIZE;
> + }
> +
> dev_priv->perf.oa.oa_buffer.format_size = format_size;
> if (WARN_ON(dev_priv->perf.oa.oa_buffer.format_size == 0))
> return -EINVAL;
> @@ -2857,6 +2881,9 @@ static int read_properties_unlocked(struct drm_i915_private *dev_priv,
> case DRM_I915_PERF_PROP_SAMPLE_GPU_TS:
> props->sample_flags |= SAMPLE_GPU_TS;
> break;
> + case DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS:
> + props->sample_flags |= SAMPLE_SYSTEM_TS;
> + break;
> case DRM_I915_PERF_PROP_OA_METRICS_SET:
> if (value == 0) {
> DRM_DEBUG("Unknown OA metric set ID\n");
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 0b9249e..283859c 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1453,6 +1453,12 @@ enum drm_i915_perf_property_id {
> DRM_I915_PERF_PROP_SAMPLE_GPU_TS,
>
> /**
> + * This property requests inclusion of CLOCK_MONOTONIC system time in
> + * the perf sample data.
> + */
> + DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS,
> +
> + /**
> * The value specifies which set of OA unit metrics should be
> * be configured, defining the contents of any OA unit reports.
> */
> @@ -1539,6 +1545,7 @@ enum drm_i915_perf_record_type {
> *
> * { u32 oa_report[]; } && DRM_I915_PERF_PROP_SAMPLE_OA
> * { u64 gpu_timestamp; } && DRM_I915_PERF_PROP_SAMPLE_GPU_TS
> + * { u64 system_timestamp; } && DRM_I915_PERF_PROP_SAMPLE_SYSTEM_TS
> * };
> */
> DRM_I915_PERF_RECORD_SAMPLE = 1,
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-11-15 17:54 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 [this message]
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
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=e7216086-96a1-d07e-f305-caa839399c8d@intel.com \
--to=sagar.a.kamble@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=sourab.gupta@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