From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Ramalingam C <ramalingam.c@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 08:26:20 +0100 [thread overview]
Message-ID: <647fc10a-3b71-cd36-135e-9ae6bfd0e271@linux.intel.com> (raw)
In-Reply-To: <20190624054524.GB1498@intel.com>
On 24/06/2019 06:45, Ramalingam C wrote:
> 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 think intel_execution_engine2 is not always available. For instance
perf_pmu/frequency|interrupts it is not.
Maybe change struct intel_execution_engine2 to embed struct
i915_engine_class_instance instead of having separate class and instance
fields? So in tests where you have it you can just pass e2->engine?
Maybe it would require too much churn, not sure.
For the option with less churn we can have two or more flavours of the
helper. One can take class and instance separately, one can take ci and
one struct intel_execution_engine2 if that makes sense.
Regards,
Tvrtko
> 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, ¶m)) {
>>> + 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
next prev parent reply other threads:[~2019-06-24 7:26 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
2019-06-24 7:26 ` Tvrtko Ursulin [this message]
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=647fc10a-3b71-cd36-135e-9ae6bfd0e271@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=andi@etezian.org \
--cc=igt-dev@lists.freedesktop.org \
--cc=ramalingam.c@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