From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: akash.goel@intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v9] drm/i915: Allocate intel_engine_cs structure only for the enabled engines
Date: Fri, 07 Oct 2016 13:49:56 +0300 [thread overview]
Message-ID: <1475837396.6623.22.camel@linux.intel.com> (raw)
In-Reply-To: <1475832782-25326-1-git-send-email-akash.goel@intel.com>
On pe, 2016-10-07 at 15:03 +0530, akash.goel@intel.com wrote:
> > From: Akash Goel <akash.goel@intel.com>
>
> With the possibility of addition of many more number of rings in future,
> the drm_i915_private structure could bloat as an array, of type
> intel_engine_cs, is embedded inside it.
> struct intel_engine_cs engine[I915_NUM_ENGINES];
> Though this is still fine as generally there is only a single instance of
> drm_i915_private structure used, but not all of the possible rings would be
> enabled or active on most of the platforms. Some memory can be saved by
> allocating intel_engine_cs structure only for the enabled/active engines.
> Currently the engine/ring ID is kept static and dev_priv->engine[] is simply
> indexed using the enums defined in intel_engine_id.
> To save memory and continue using the static engine/ring IDs, 'engine' is
> defined as an array of pointers.
> struct intel_engine_cs *engine[I915_NUM_ENGINES];
> dev_priv->engine[engine_ID] will be NULL for disabled engine instances.
>
> v2:
> - Remove the engine iterator field added in drm_i915_private structure,
> instead pass a local iterator variable to the for_each_engine**
> macros. (Chris)
> - Do away with intel_engine_initialized() and instead directly use the
> NULL pointer check on engine pointer. (Chris)
>
> v3:
> - Remove for_each_engine_id() macro, as the updated macro for_each_engine()
> can be used in place of it. (Chris)
> - Protect the access to Render engine Fault register with a NULL check, as
> engine specific init is done later in Driver load sequence.
>
> v4:
> - Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris)
> - Kill the superfluous init_engine_lists().
>
> v5:
> - Cleanup the intel_engines_init() & intel_engines_setup(), with respect to
> allocation of intel_engine_cs structure. (Chris)
>
> v6:
> - Rebase.
>
> v7:
> - Optimize the for_each_engine_masked() macro. (Chris)
> - Change the type of 'iter' local variable to enum intel_engine_id. (Chris)
> - Rebase.
>
Would not it be consistent to go with 'id' everywhere rather than
'iter'. Consistency is good, and my vote for 'id' as it's more
descriptive?
> @@ -153,9 +163,9 @@ int intel_engines_init(struct drm_device *dev)
> cleanup:
> for (i = 0; i < I915_NUM_ENGINES; i++) {
Use for_each_engine here too.
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 936f6f6..08303e3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1645,7 +1645,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv;
>
> - if (!intel_engine_initialized(engine))
> + if (!engine)
> return;
Remove this check or make it GEM_BUG_ON(!engine); but I don't think we
need that much paranoia.
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
<SNIP>
> @@ -2091,7 +2092,7 @@ void intel_engine_cleanup(struct intel_engine_cs *engine)
> {
> > struct drm_i915_private *dev_priv;
>
> - if (!intel_engine_initialized(engine))
> + if (!engine)
> return;
Same as above.
With those points fixed;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-10-07 10:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-07 9:33 [PATCH v9] drm/i915: Allocate intel_engine_cs structure only for the enabled engines akash.goel
2016-10-07 9:58 ` ✗ Fi.CI.BAT: failure for " Patchwork
2016-10-07 11:44 ` Chris Wilson
2016-10-07 11:53 ` Goel, Akash
2016-10-07 10:49 ` Joonas Lahtinen [this message]
2016-10-07 13:24 ` [PATCH v9] " akash goel
2016-10-07 19:11 ` [PATCH v10] " akash.goel
2016-10-10 12:33 ` ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) Patchwork
2016-10-13 16:10 ` Goel, Akash
2016-10-13 16:28 ` Tvrtko Ursulin
2016-10-13 17:14 ` [PATCH v11] drm/i915: Allocate intel_engine_cs structure only for the enabled engines akash.goel
2016-10-13 18:47 ` ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3) Saarinen, Jani
2016-10-13 19:57 ` Chris Wilson
2016-10-14 6:03 ` Saarinen, Jani
2016-10-14 10:37 ` Petri Latvala
2016-10-14 11:01 ` Chris Wilson
2016-10-13 17:20 ` ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4) Patchwork
2016-10-14 9:02 ` Goel, Akash
2016-10-14 9:04 ` Tvrtko Ursulin
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=1475837396.6623.22.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=akash.goel@intel.com \
--cc=intel-gfx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox