From: Andi Shyti <andi@etezian.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: IGT dev <igt-dev@lists.freedesktop.org>,
Andi Shyti <andi@etezian.org>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface
Date: Mon, 26 Nov 2018 11:07:37 +0200 [thread overview]
Message-ID: <20181126090737.GA1745@jack.zhora.eu> (raw)
In-Reply-To: <f8355c69-2b92-65c1-e51c-d309531d2db7@linux.intel.com>
Hi Tvrtko,
just few things that came to my mind while going through your
review.
> > + query_engines = malloc(size);
> > + if (!query_engines)
> > + return NULL;
>
> We probably want to igt_assert on this since there is no point going
> further.
isn't igt_assert used for the test outcome? What I mean is that
the test outcome would be to query and set the engines, but if we
fail in malloc we do not necessarily fail the test, but we have a
different kind of system failure.
(this is not important, just for me to understand better :) )
> > +int get_engines(int fd, uint32_t ctx_id)
>
> setup_ctx_engines?
>
> Does it need to be exported or it can be static?
How do we reach it from outside if we set it static? This
function is called in the for_each_engine_ctx macro that is used
outside from igt_gt.c
> > +#define for_each_engine_ctx(fd, ctx, e) \
>
> High level design question: Do we want 'e' to be an integer or a struct
> describing each engine?
Do you mean that you would you prefer iterating with a
'i915_context_param_engines' or a 'intel_execution_engine' struct
instead of an 'e' integer? This way it would also be different
from how the current 'for_each_engine' works.
I could do it in a next patch, so that in this one we keep it as
close as possible to the current way of doing things.
Andi
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2018-11-26 9:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 16:10 [igt-dev] [RFC v2 0/3] new engine discovery interface Andi Shyti
2018-11-21 16:10 ` [igt-dev] [RFC v2 1/3] include/drm-uapi: import i915_drm.h header file Andi Shyti
2018-11-21 16:10 ` [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface Andi Shyti
2018-11-22 12:14 ` Tvrtko Ursulin
2018-11-22 13:28 ` Andi Shyti
2018-11-26 9:07 ` Andi Shyti [this message]
2018-11-26 9:27 ` Tvrtko Ursulin
2018-11-21 16:10 ` [igt-dev] [RFC v2 3/3] tests: gem_gem_query_engines_demo: create test Andi Shyti
2018-11-22 12:25 ` Tvrtko Ursulin
2018-11-21 16:51 ` [igt-dev] ✓ Fi.CI.BAT: success for new engine discovery interface (rev2) Patchwork
2018-11-22 2:45 ` [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=20181126090737.GA1745@jack.zhora.eu \
--to=andi@etezian.org \
--cc=igt-dev@lists.freedesktop.org \
--cc=tvrtko.ursulin@intel.com \
--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.