All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramalingam C <ramalingam.c@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: IGT dev <igt-dev@lists.freedesktop.org>, Andi Shyti <andi@etezian.org>
Subject: Re: [igt-dev] [PATCH v2] lib/i915: gem_engine_topology: get eb flags from engine's class:instance
Date: Mon, 24 Jun 2019 11:15:24 +0530	[thread overview]
Message-ID: <20190624054524.GB1498@intel.com> (raw)
In-Reply-To: <ca53b69d-3e1c-9cf6-6b49-a80f1ee7385e@linux.intel.com>

On 2019-06-20 at 17:14:38 +0100, Tvrtko Ursulin wrote:
> 
> On 20/06/2019 14:14, Andi Shyti wrote:
> > The execution buffer flag value has now the engine index as it is
> > mapped in the context. Retrieve the mapped index by interrogating
> > the driver starting from the class/instance tuple.
> > 
> > A "gem_context_get_eb_flags_ci" helper allows to avoid declaring
> > a "struct i915_engine_class_instance" for the purpose.
> > 
> > Return -EINVAL if the engine is not mapped in the given context.
> > 
> > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Signed-off-by: Andi Shyti <andi.shyti@intel.com>
> > Cc: Ramalingam C <ramalingam.c@intel.com>
> > ---
> > V1 --> V2 changelog:
> > --------------------
> > - refactor the code to avoid initializing the context just for
> >    the purpose of getting the execution buffer flag (thanks
> >    Tvrtko)
> > 
> >   lib/i915/gem_engine_topology.c | 31 +++++++++++++++++++++++++++++++
> >   lib/i915/gem_engine_topology.h |  6 ++++++
> >   2 files changed, 37 insertions(+)
> > 
> > diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
> > index fdd1b951672b..fd5be3491b89 100644
> > --- a/lib/i915/gem_engine_topology.c
> > +++ b/lib/i915/gem_engine_topology.c
> > @@ -270,6 +270,37 @@ int gem_context_lookup_engine(int fd, uint64_t engine, uint32_t ctx_id,
> >   	return 0;
> >   }
> > +int gem_context_get_eb_flags(int fd, uint32_t ctx_id,
> > +			     struct i915_engine_class_instance *ci)
tvrtko and Andi,

instead of creating the i915_engine_class_instance on the go, can't we have the
intel_execution_engine2 * itself passed to this function? Anyway engine2
pointer will be available in all the time this function is called.

I am using this patch for
s/for_each_physical_engine/__for_each_physical_engine. Shall do the above change and submit?

-Ram
> > +{
> > +	DEFINE_CONTEXT_ENGINES_PARAM(engines, param, ctx_id, GEM_MAX_ENGINES);
> > +
> > +	/* legacy kernels */
> > +	if (gem_topology_get_param(fd, &param)) {
> > +		const struct intel_execution_engine2 *e;
> > +
> > +		__for_each_static_engine(e)
> > +			if (e->class == ci->engine_class &&
> > +			    e->instance == ci->engine_instance)
> > +				return e->flags;
> > +
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* context has no engine mapped */
> > +	if (!param.size)
> > +		return -EINVAL;
> > +
> > +	/* engine map lookup */
> > +	for (int i = 0; i < param.size; i++)
> > +		if (engines.engines[i].engine_class == ci->engine_class &&
> > +		    engines.engines[i].engine_instance == ci->engine_instance)
> > +			return i;
> > +
> > +	/* engine is not mapped in the given context */
> > +	return -EINVAL;
> > +}
> 
> Looks good to me.. ;)
> 
> > +
> >   void gem_context_set_all_engines(int fd, uint32_t ctx)
> >   {
> >   	DEFINE_CONTEXT_ENGINES_PARAM(engines, param, ctx, GEM_MAX_ENGINES);
> > diff --git a/lib/i915/gem_engine_topology.h b/lib/i915/gem_engine_topology.h
> > index 2415fd1e379b..57b5473bbd5a 100644
> > --- a/lib/i915/gem_engine_topology.h
> > +++ b/lib/i915/gem_engine_topology.h
> > @@ -53,6 +53,12 @@ int gem_context_lookup_engine(int fd, uint64_t engine, uint32_t ctx_id,
> >   void gem_context_set_all_engines(int fd, uint32_t ctx);
> > +int gem_context_get_eb_flags(int fd, uint32_t ctx_id,
> > +			     struct i915_engine_class_instance *ci);
> > +
> > +#define gem_context_get_eb_flags_ci(f, c, ...) \
> > +	gem_context_get_eb_flags(f, c, &((struct i915_engine_class_instance){__VA_ARGS__}))
> > +
> 
> Hah this is some trick. I assume this allows:
> 
> eb.flags = gem_context_get_eb_flags(fd, ctx, ..._RENDER, 0);
> 
> ?
> 
> What if too few or too many parameters are given? I'm in two minds but can't
> argue it is very to be able to do this in IGT.
> 
> >   #define __for_each_static_engine(e__) \
> >   	for ((e__) = intel_execution_engines2; (e__)->name; (e__)++)
> > 
> 
> Can you extend the series with a patch which converts the problematic
> subtests in perf_pmu to use this helper? Or even merge into this patch, I
> don't mind. Would have some moral grounds to r-b it then. ;)
> 
> Regards,
> 
> Tvrtko
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-06-24  5:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20 13:14 [igt-dev] [PATCH v2] lib/i915: gem_engine_topology: get eb flags from engine's class:instance Andi Shyti
2019-06-20 16:14 ` Tvrtko Ursulin
2019-06-24  5:45   ` Ramalingam C [this message]
2019-06-24  7:26     ` Tvrtko Ursulin
2019-06-25 11:34       ` Andi Shyti
2019-06-20 17:19 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-06-20 21:47 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork

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=20190624054524.GB1498@intel.com \
    --to=ramalingam.c@intel.com \
    --cc=andi@etezian.org \
    --cc=igt-dev@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 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.