All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Shyti <andi.shyti@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: IGT dev <igt-dev@lists.freedesktop.org>, Andi Shyti <andi@etezian.org>
Subject: Re: [igt-dev] [PATCH v14 4/5] lib/i915: add gem_engine_topology library and for_each loop definition
Date: Thu, 21 Mar 2019 13:38:21 +0200	[thread overview]
Message-ID: <20190321113821.GB1774@intel.intel> (raw)
In-Reply-To: <155315355875.22764.5134530389425285211@skylake-alporthouse-com>

Hi Chris,

> > +static void query_engines(int fd,
> > +                         struct drm_i915_query_engine_info *query_engines)
> 
> Pass in the length of the query_engines block i.e. don't just assume
> item.length. And I'm still worrying about what happens when it is
> greater than 64 engines.

OK, looks the same to me, but sure, I can set item.length
outside query_engines().

> > +       if (__gem_context_get_param(fd, &param)) {
> > +               /* if kernel does not support engine/context mapping */
> 
> We also take this path if we have more than 64 engines.

But I haven't found anywhere in the get_param() and
i915_query_ioctl() in the driver where this case is considered.

Don't we receive -EINVAL only when "args->size < size"?

The set_engines would fail if we try to do that. I don't see this
a plausible thing to happen (unless, of course, I missed it,
which is very likely).

In any case, we don't have an error control in engine_data and we
would never understand whether there is somthing screwed up.

I was thinking that I can add in the structure an "error"
variable so that we quit the loop if something wrong happens,
e.g. we receive size > 3f.

> > +               __for_each_engine_class_instance(e2) {
> > +                       uint64_t flags;
> > +
> > +                       if (!gem_has_engine(fd, e2->class, e2->instance))
> > +                               continue;
> > +
> > +                       flags = gem_class_instance_to_eb_flags(fd, e2->class,
> > +                                                              e2->instance);
> 
> You added the field to the static struct, you might as well populate it
> as well, and just use e2->flags. And then you wouldn't even need to
> repeat the computation for gem_has_engine.

makes sense.

> > +struct intel_engine_data intel_init_engine_list(int fd, uint32_t ctx_id);
> > +
> > +#endif /* GEM_ENGINE_TOPOLOGY_H */
> > diff --git a/lib/igt_gt.h b/lib/igt_gt.h
> > index 475c0b3c3cc6..84ea4af5392d 100644
> > --- a/lib/igt_gt.h
> > +++ b/lib/igt_gt.h
> 
> And we need to break away from igt_gt.h, these will all be good inside
> gem_engine_topology.h I think.

I was thinking the same, but given that all the for_each are in
igt_gt.h I guess that's the right place for consistence, unless
we move all the for_each, until we will get rid of all the
legacy.

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

  reply	other threads:[~2019-03-21 11:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21  1:00 [igt-dev] [PATCH v14 0/5] new engine discovery interface Andi Shyti
2019-03-21  1:00 ` [igt-dev] [PATCH v14 1/5] lib/igt_gt: remove unnecessary argument Andi Shyti
2019-03-21  1:00 ` [igt-dev] [PATCH v14 2/5] lib: ioctl_wrappers: reach engines by index as well Andi Shyti
2019-03-21  1:05   ` Chris Wilson
2019-03-21 10:12     ` Andi Shyti
2019-03-21  7:06   ` Tvrtko Ursulin
2019-03-21  1:00 ` [igt-dev] [PATCH v14 3/5] include/drm-uapi: import i915_drm.h header file Andi Shyti
2019-03-21  1:00 ` [igt-dev] [PATCH v14 4/5] lib/i915: add gem_engine_topology library and for_each loop definition Andi Shyti
2019-03-21  7:18   ` Tvrtko Ursulin
2019-03-21 11:23     ` Andi Shyti
2019-03-21 11:39       ` Tvrtko Ursulin
2019-03-21 11:54         ` Chris Wilson
2019-03-21 11:57           ` Chris Wilson
2019-03-21 12:18         ` Andi Shyti
2019-03-21  7:32   ` Chris Wilson
2019-03-21 11:38     ` Andi Shyti [this message]
2019-03-21  1:00 ` [igt-dev] [PATCH v14 5/5] tests: gem_exec_basic: add "exec-ctx" buffer execution demo test Andi Shyti
2019-03-21  1:29 ` [igt-dev] ✓ Fi.CI.BAT: success for new engine discovery interface Patchwork
2019-03-21  9:01 ` [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=20190321113821.GB1774@intel.intel \
    --to=andi.shyti@intel.com \
    --cc=andi@etezian.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    /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.