public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@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 v16 6/8] lib: igt_gt: make gem_engine_can_store_dword() check engine class
Date: Fri, 29 Mar 2019 14:43:34 +0200	[thread overview]
Message-ID: <20190329124334.GD1167@intel.intel> (raw)
In-Reply-To: <5962ecab-4406-96a1-c279-0efba329356e@linux.intel.com>

> > +bool gem_can_store_dword(int fd, uint64_t engine)
> 
> Yeah eb->flags is u64, although we don't need it all here. Okay, I don't mind.

here flags (u64), class (u16) and engine (u8 is enough) are
somehow confusingly mixed... need to check better the type range
I need.

> > +bool gem_engine_can_store_dword(int fd, const struct intel_execution_engine2 *e)
> > +{
> > +	if (!gem_has_engine_topology(fd))
> > +		return gem_can_store_dword(fd, e->flags);
> > +
> > +	return gem_class_can_store_dword(fd, e->class);
> > +}
> 
> Couldn't you always use class?

How do you distinguish between eb flags as engine and context
mapping, then?

In theory this function should not work in all the cases, because
it assumes that e->flags has always a meningful value.

While if this is called during a __for_each_static_engine (which
should never be used in my dream world), flags is always '0'. In
the next patches I tried to be careful to this case (_tried_, eh?  :) )

(BTW, this is a proposal, because the legacy usage of
intel_execution_engines2 list is used a lot)

> bool gem_can_store_dword(int fd, uint64_t engine)
> {
> 	u16 class = eb_engine_to_class(engine);

Yes, I need this extra step, assuming that engine is always an
eb_flag.

In the last patchset you recommended the following:

  // ioctl and stuff.. bummer... :(
  ret = gem_context_get_engine_map_class_instance(fd, opts->ctx, opts->engine,
  &class, &instance);     
  if (ret) // error = no map = means opts->engine is eb flags
          check legacy gem_can_store_dword
  else
          check using new gem_engine_can_store_dword(class, instance)

which I did here (still it works only out from
__for_each_static_engine).

Andi
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-03-29 12:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-28 19:21 [igt-dev] [RFC v16 0/8] new engine discovery interface Andi Shyti
2019-03-28 19:21 ` [igt-dev] [PATCH v16 1/8] lib/igt_gt: remove unnecessary argument Andi Shyti
2019-03-29 11:34   ` Tvrtko Ursulin
2019-03-28 19:22 ` [igt-dev] [PATCH v16 2/8] lib: ioctl_wrappers: reach engines by index as well Andi Shyti
2019-03-29 11:36   ` Tvrtko Ursulin
2019-03-29 11:59     ` Andi Shyti
2019-03-28 19:22 ` [igt-dev] [PATCH v16 3/8] include/drm-uapi: import i915_drm.h header file Andi Shyti
2019-03-28 19:22 ` [igt-dev] [PATCH v16 4/8] lib/i915: add gem_engine_topology library and for_each loop definition Andi Shyti
2019-03-29 11:34   ` Tvrtko Ursulin
2019-03-29 12:05     ` Andi Shyti
2019-03-28 19:22 ` [igt-dev] [PATCH v16 5/8] tests: gem_exec_basic: add engine discovery test Andi Shyti
2019-03-29 11:39   ` Tvrtko Ursulin
2019-03-29 12:06     ` Andi Shyti
2019-03-29 12:41       ` Tvrtko Ursulin
2019-03-29 23:36   ` Chris Wilson
2019-03-31 17:36     ` Andi Shyti
2019-03-31 17:42       ` Chris Wilson
2019-03-31 20:19         ` Andi Shyti
2019-03-28 19:22 ` [igt-dev] [PATCH v16 6/8] lib: igt_gt: make gem_engine_can_store_dword() check engine class Andi Shyti
2019-03-29 12:22   ` Tvrtko Ursulin
2019-03-29 12:43     ` Andi Shyti [this message]
2019-03-28 19:22 ` [igt-dev] [PATCH v16 7/8] lib: igt_dummyload: use for_each_context_engine() Andi Shyti
2019-03-29 12:33   ` Tvrtko Ursulin
2019-03-28 19:22 ` [igt-dev] [PATCH v16 8/8] test: perf_pmu: use the gem_engine_topology library Andi Shyti
2019-03-29 12:40   ` Tvrtko Ursulin
2019-03-29 12:47     ` Andi Shyti
2019-03-29 12:56       ` Tvrtko Ursulin
2019-03-28 20:15 ` [igt-dev] ✓ Fi.CI.BAT: success for new engine discovery interface Patchwork
2019-03-29  7:40 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=20190329124334.GD1167@intel.intel \
    --to=andi.shyti@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox