intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 24/47] drm/i915/guc: Add several request trace points
Date: Mon, 19 Jul 2021 18:59:59 -0700	[thread overview]
Message-ID: <20210720015959.GA14012@sdutt-i7> (raw)
In-Reply-To: <e5d96ebb-f168-c1af-22c8-0b066388e70d@linux.intel.com>

On Tue, Jul 13, 2021 at 10:06:17AM +0100, Tvrtko Ursulin wrote:
> 
> On 24/06/2021 08:04, Matthew Brost wrote:
> > Add trace points for request dependencies and GuC submit. Extended
> > existing request trace points to include submit fence value,, guc_id,
> > and ring tail value.
> > 
> > Cc: John Harrison <john.c.harrison@intel.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >   .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  3 ++
> >   drivers/gpu/drm/i915/i915_request.c           |  3 ++
> >   drivers/gpu/drm/i915/i915_trace.h             | 39 ++++++++++++++++++-
> >   3 files changed, 43 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 89b3c7e5d15b..c2327eebc09c 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -422,6 +422,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
> >   			guc->stalled_request = last;
> >   			return false;
> >   		}
> > +		trace_i915_request_guc_submit(last);
> >   	}
> >   	guc->stalled_request = NULL;
> > @@ -642,6 +643,8 @@ static int guc_bypass_tasklet_submit(struct intel_guc *guc,
> >   	ret = guc_add_request(guc, rq);
> >   	if (ret == -EBUSY)
> >   		guc->stalled_request = rq;
> > +	else
> > +		trace_i915_request_guc_submit(rq);
> >   	return ret;
> >   }
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index d92c9f25c9f4..7f7aa096e873 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1344,6 +1344,9 @@ __i915_request_await_execution(struct i915_request *to,
> >   			return err;
> >   	}
> > +	trace_i915_request_dep_to(to);
> > +	trace_i915_request_dep_from(from);
> 
> Are those two guaranteed to be atomic ie. no other dep_to/dep_from can get
> injected in the middle of them and if so what guarantees that?
>

These are not atomic but in practice I've never seen an out of order
tracepoints.
 
> Actually we had an internal discussion going in November 2019 on these very
> tracepoints which I think was left hanging in the air.
> 
> There I was suggesting you create a single tracepoint in the format of "from
> -> to", so it's clear without any doubt what is going on.
>

Not sure if it worth adding a custom trace point fo rthis.
 
> I also suggested this should out outside the GuC patch since it is backend
> agnostic.

I guess, but it really matter?

> 
> I also asked why only this flavour of dependencies and not all. You said
> this was the handy one for debugging GuC backend issues. I said in that case
> you should name it trace_i915_request_await_request so it is clearer it does
> not cover all dependencies.
>

Can't we look at the code? For kernel dev trace point I don't this it is
to much to ask a developer to grep around the code. Also you likely only
turn these on if you know what you are doing anyways.
 
> As it stands it is a bit misleadingly named, has that question mark around
> atomicity, and also is not GuC specific. So really I wouldn't think it
> passes the bar in the current state.

I'll just delete them.

> Regards,
> 
> Tvrtko
> 
> P.S. Same discussion from 2019 also talked about
> trace_i915_request_guc_submit and how it exactly aligns to existing request
> in tracepoint.

I doesn't align. You literally make the point about how it doesn't align
below.

> You were saying the new one is handy because it corresponds
> with H2G, as the last request_in of the group would trigger it. I was saying
> that then you could either know implicitly last request_in triggers H2G, or
> that you could consider adding explicit H2G tracepoints.

Yes, we have a trace point for every H2G. Again the users of these
tracepoints know what they mean.

Matt

> 
> > +
> >   	/* Couple the dependency tree for PI on this exposed to->fence */
> >   	if (to->engine->sched_engine->schedule) {
> >   		err = i915_sched_node_add_dependency(&to->sched,
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> > index 6778ad2a14a4..b02d04b6c8f6 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -794,22 +794,27 @@ DECLARE_EVENT_CLASS(i915_request,
> >   	    TP_STRUCT__entry(
> >   			     __field(u32, dev)
> >   			     __field(u64, ctx)
> > +			     __field(u32, guc_id)
> >   			     __field(u16, class)
> >   			     __field(u16, instance)
> >   			     __field(u32, seqno)
> > +			     __field(u32, tail)
> >   			     ),
> >   	    TP_fast_assign(
> >   			   __entry->dev = rq->engine->i915->drm.primary->index;
> >   			   __entry->class = rq->engine->uabi_class;
> >   			   __entry->instance = rq->engine->uabi_instance;
> > +			   __entry->guc_id = rq->context->guc_id;
> >   			   __entry->ctx = rq->fence.context;
> >   			   __entry->seqno = rq->fence.seqno;
> > +			   __entry->tail = rq->tail;
> >   			   ),
> > -	    TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
> > +	    TP_printk("dev=%u, engine=%u:%u, guc_id=%u, ctx=%llu, seqno=%u, tail=%u",
> >   		      __entry->dev, __entry->class, __entry->instance,
> > -		      __entry->ctx, __entry->seqno)
> > +		      __entry->guc_id, __entry->ctx, __entry->seqno,
> > +		      __entry->tail)
> >   );
> >   DEFINE_EVENT(i915_request, i915_request_add,
> > @@ -818,6 +823,21 @@ DEFINE_EVENT(i915_request, i915_request_add,
> >   );
> >   #if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
> > +DEFINE_EVENT(i915_request, i915_request_dep_to,
> > +	     TP_PROTO(struct i915_request *rq),
> > +	     TP_ARGS(rq)
> > +);
> > +
> > +DEFINE_EVENT(i915_request, i915_request_dep_from,
> > +	     TP_PROTO(struct i915_request *rq),
> > +	     TP_ARGS(rq)
> > +);
> > +
> > +DEFINE_EVENT(i915_request, i915_request_guc_submit,
> > +	     TP_PROTO(struct i915_request *rq),
> > +	     TP_ARGS(rq)
> > +);
> > +
> >   DEFINE_EVENT(i915_request, i915_request_submit,
> >   	     TP_PROTO(struct i915_request *rq),
> >   	     TP_ARGS(rq)
> > @@ -887,6 +907,21 @@ TRACE_EVENT(i915_request_out,
> >   #else
> >   #if !defined(TRACE_HEADER_MULTI_READ)
> > +static inline void
> > +trace_i915_request_dep_to(struct i915_request *rq)
> > +{
> > +}
> > +
> > +static inline void
> > +trace_i915_request_dep_from(struct i915_request *rq)
> > +{
> > +}
> > +
> > +static inline void
> > +trace_i915_request_guc_submit(struct i915_request *rq)
> > +{
> > +}
> > +
> >   static inline void
> >   trace_i915_request_submit(struct i915_request *rq)
> >   {
> > 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-07-20  2:11 UTC|newest]

Thread overview: 170+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24  7:04 [Intel-gfx] [PATCH 00/47] GuC submission support Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 01/47] drm/i915/guc: Relax CTB response timeout Matthew Brost
2021-06-24 17:23   ` Michal Wajdeczko
2021-06-24  7:04 ` [Intel-gfx] [PATCH 02/47] drm/i915/guc: Improve error message for unsolicited CT response Matthew Brost
2021-06-25 11:58   ` Michal Wajdeczko
2021-06-24  7:04 ` [Intel-gfx] [PATCH 03/47] drm/i915/guc: Increase size of CTB buffers Matthew Brost
2021-06-24 13:49   ` Michal Wajdeczko
2021-06-24 15:41     ` Matthew Brost
2021-06-25 12:03       ` Michal Wajdeczko
2021-06-24  7:04 ` [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function Matthew Brost
2021-06-24 14:48   ` Michal Wajdeczko
2021-06-24 15:49     ` Matthew Brost
2021-06-24 17:02       ` Michal Wajdeczko
2021-06-24 22:41         ` Matthew Brost
2021-06-25 11:50           ` Michal Wajdeczko
2021-06-25 17:53             ` Matthew Brost
2021-06-24 22:47         ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 05/47] drm/i915/guc: Add stall timer to " Matthew Brost
2021-06-24 17:37   ` Michal Wajdeczko
2021-06-24 23:01     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 06/47] drm/i915/guc: Optimize CTB writes and reads Matthew Brost
2021-06-25 13:09   ` Michal Wajdeczko
2021-06-25 18:26     ` Matthew Brost
2021-06-25 20:28     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 07/47] drm/i915/guc: Module load failure test for CT buffer creation Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 08/47] drm/i915/guc: Add new GuC interface defines and structures Matthew Brost
2021-06-29 21:11   ` John Harrison
2021-06-30  0:30     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 09/47] drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor Matthew Brost
2021-06-25 19:44   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 10/47] drm/i915/guc: Add lrc descriptor context lookup array Matthew Brost
2021-06-25 13:17   ` Michal Wajdeczko
2021-06-25 17:26     ` Matthew Brost
2021-06-29 21:20       ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 11/47] drm/i915/guc: Implement GuC submission tasklet Matthew Brost
2021-06-29 22:04   ` John Harrison
2021-06-30  0:41     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 12/47] drm/i915/guc: Add bypass tasklet submission path to GuC Matthew Brost
2021-06-29 22:09   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 13/47] drm/i915/guc: Implement GuC context operations for new inteface Matthew Brost
2021-06-25 13:25   ` Michal Wajdeczko
2021-06-25 17:46     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 14/47] drm/i915/guc: Insert fence on context when deregistering Matthew Brost
2021-07-09 22:39   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 15/47] drm/i915/guc: Defer context unpin until scheduling is disabled Matthew Brost
2021-07-09 22:48   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 16/47] drm/i915/guc: Disable engine barriers with GuC during unpin Matthew Brost
2021-07-09 22:53   ` John Harrison
2021-07-10  3:00     ` Matthew Brost
2021-07-12 17:57       ` John Harrison
2021-07-12 18:11         ` Daniel Vetter
2021-06-24  7:04 ` [Intel-gfx] [PATCH 17/47] drm/i915/guc: Extend deregistration fence to schedule disable Matthew Brost
2021-07-09 22:59   ` John Harrison
2021-07-10  3:36     ` Matthew Brost
2021-07-12 17:54       ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 18/47] drm/i915: Disable preempt busywait when using GuC scheduling Matthew Brost
2021-07-09 23:03   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 19/47] drm/i915/guc: Ensure request ordering via completion fences Matthew Brost
2021-07-15  1:51   ` Daniele Ceraolo Spurio
2021-06-24  7:04 ` [Intel-gfx] [PATCH 20/47] drm/i915/guc: Disable semaphores when using GuC scheduling Matthew Brost
2021-07-09 23:53   ` John Harrison
2021-07-15  0:07     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 21/47] drm/i915/guc: Ensure G2H response has space in buffer Matthew Brost
2021-07-13 18:36   ` John Harrison
2021-07-15  0:06     ` Matthew Brost
2021-07-15  0:12       ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 22/47] drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC Matthew Brost
2021-07-10  0:16   ` John Harrison
2021-07-10  3:55     ` Matthew Brost
2021-07-17  4:09       ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC Matthew Brost
2021-07-12 18:05   ` John Harrison
2021-07-12 20:59     ` Matthew Brost
2021-07-12 21:37       ` John Harrison
2021-07-13  8:51   ` Michal Wajdeczko
2021-07-14 23:56     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 24/47] drm/i915/guc: Add several request trace points Matthew Brost
2021-07-12 18:08   ` John Harrison
2021-07-13  9:06   ` Tvrtko Ursulin
2021-07-20  1:59     ` Matthew Brost [this message]
2021-07-22 13:55       ` Tvrtko Ursulin
2021-06-24  7:04 ` [Intel-gfx] [PATCH 25/47] drm/i915: Add intel_context tracing Matthew Brost
2021-07-12 18:10   ` John Harrison
2021-07-12 21:47     ` Matthew Brost
2021-07-12 21:51       ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 26/47] drm/i915/guc: GuC virtual engines Matthew Brost
2021-07-15  1:21   ` Daniele Ceraolo Spurio
2021-06-24  7:04 ` [Intel-gfx] [PATCH 27/47] drm/i915: Track 'serial' counts for " Matthew Brost
2021-07-12 18:11   ` John Harrison
2021-07-12 20:06     ` Matthew Brost
2021-06-24  7:04 ` [Intel-gfx] [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request Matthew Brost
2021-07-12 18:23   ` John Harrison
2021-07-12 20:05     ` Matthew Brost
2021-07-12 21:36       ` Matthew Brost
2021-07-12 21:48         ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 29/47] drm/i915/guc: Disable bonding extension with GuC submission Matthew Brost
2021-07-12 18:23   ` John Harrison
2021-06-24  7:04 ` [Intel-gfx] [PATCH 30/47] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs Matthew Brost
2021-07-12 19:19   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 31/47] drm/i915/guc: Reset implementation for new GuC interface Matthew Brost
2021-07-12 19:58   ` John Harrison
2021-07-15  0:53     ` Matthew Brost
2021-07-15  9:36   ` Tvrtko Ursulin
2021-07-26 22:48     ` Matthew Brost
2021-07-27  8:56       ` Tvrtko Ursulin
2021-07-27 18:30         ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 32/47] drm/i915: Reset GPU immediately if submission is disabled Matthew Brost
2021-07-12 20:01   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 33/47] drm/i915/guc: Add disable interrupts to guc sanitize Matthew Brost
2021-07-12 20:11   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 34/47] drm/i915/guc: Suspend/resume implementation for new interface Matthew Brost
2021-07-12 22:56   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 35/47] drm/i915/guc: Handle context reset notification Matthew Brost
2021-07-12 22:58   ` John Harrison
2021-07-15  0:32     ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 36/47] drm/i915/guc: Handle engine reset failure notification Matthew Brost
2021-07-12 22:59   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 37/47] drm/i915/guc: Enable the timer expired interrupt for GuC Matthew Brost
2021-07-12 23:00   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 38/47] drm/i915/guc: Provide mmio list to be saved/restored on engine reset Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 39/47] drm/i915/guc: Don't complain about reset races Matthew Brost
2021-06-24 15:55   ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 40/47] drm/i915/guc: Enable GuC engine reset Matthew Brost
2021-06-24 16:19   ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 41/47] drm/i915/guc: Capture error state on context reset Matthew Brost
2021-07-12 23:05   ` John Harrison
2021-06-24  7:05 ` [Intel-gfx] [PATCH 42/47] drm/i915/guc: Fix for error capture after full GPU reset with GuC Matthew Brost
2021-07-15  0:43   ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 43/47] drm/i915/guc: Hook GuC scheduling policies up Matthew Brost
2021-06-25  0:59   ` Matthew Brost
2021-06-25 19:10     ` John Harrison
2021-07-10 18:56       ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 44/47] drm/i915/guc: Connect reset modparam updates to GuC policy flags Matthew Brost
2021-06-25  1:10   ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 45/47] drm/i915/guc: Include scheduling policies in the debugfs state dump Matthew Brost
2021-06-24 16:34   ` Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 46/47] drm/i915/guc: Add golden context to GuC ADS Matthew Brost
2021-06-24  7:05 ` [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+ Matthew Brost
2021-06-30  8:22   ` Martin Peres
2021-06-30 18:00     ` Matthew Brost
2021-07-01 18:24       ` Martin Peres
2021-07-02  8:13         ` Martin Peres
2021-07-02 13:06           ` Michal Wajdeczko
2021-07-02 13:12             ` Martin Peres
2021-07-02 14:08               ` Michal Wajdeczko
2021-06-30 18:58     ` John Harrison
2021-07-01  8:14       ` Pekka Paalanen
2021-07-01 18:27         ` Martin Peres
2021-07-01 19:28           ` Daniel Vetter
2021-07-02  7:29             ` Pekka Paalanen
2021-07-02  8:09               ` Martin Peres
2021-07-02 15:07                 ` Michal Wajdeczko
2021-07-03  8:21                   ` Martin Peres
2021-07-07  0:57                     ` John Harrison
2021-07-07  7:47                       ` Pekka Paalanen
2021-07-07 10:11                       ` Michal Wajdeczko
2021-07-15  0:49   ` Matthew Brost
2021-06-24  7:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC submission support Patchwork
2021-06-24  7:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-24  7:47 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-07-12 19:23 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for GuC submission support (rev2) Patchwork
2021-10-22  9:35 ` [Intel-gfx] [PATCH 00/47] GuC submission support Joonas Lahtinen
2021-10-22 16:42   ` Matthew Brost
2021-10-25  9:37     ` Joonas Lahtinen
2021-10-25 15:15       ` Matthew Brost
2021-10-26  8:59         ` Joonas Lahtinen
2021-10-26 15:43           ` Matthew Brost
2021-10-26 15:51           ` Matthew Brost
2021-10-27  9:21             ` Joonas Lahtinen
2021-10-25 17:06       ` John Harrison

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=20210720015959.GA14012@sdutt-i7 \
    --to=matthew.brost@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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;
as well as URLs for NNTP newsgroup(s).