public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/i915: Disable dynamic setup of device_info->num_rings
Date: Mon, 12 Feb 2018 19:48:06 +0200	[thread overview]
Message-ID: <20180212174806.GV5453@intel.com> (raw)
In-Reply-To: <151825194811.9954.326739160614246099@mail.alporthouse.com>

On Sat, Feb 10, 2018 at 08:39:08AM +0000, Chris Wilson wrote:
> Quoting Oscar Mateo (2018-02-09 23:46:31)
> > 
> > On 02/09/2018 02:35 PM, Chris Wilson wrote:
> > > In order to allow the compiler to use a known constant number of
> > > available engines, disable modification of intel_device_static_info
> > > during engine bring up. Instead of trying to gracefully hide the broken
> > > setup, error out -- in theory, this should be caught during power on.
> > 
> > We are about to have a case for dynamic number of available engines. 
> > It's one of the ICL patches:
> > 
> > drm/i915/icl: Check for fused-off VDBOX and VEBOX instances
> > 
> > intel_device_runtime_info as well?
> 
> Hmm, ring_mask is more widely used than I was expecting. I think we want
> both, static_info if we ever think we can benefit from single-platform
> LTO of the engines, but whether to use runtime_info or i915->gt.engine_mask
> (and move the engine maps to i915->gt as well).
> 
> Advantage of runtime_info, centralised place for debugging.
> Disadvantage of runtime_info, centralised place far from code.
> 
> Maybe we don't need to say everything is inside runtime_info (just
> anything that doesn't fit elsewhere?), but use the hooks for debugging?
> Maybe having a central runtime_info is simply a bad idea?

Yeah, I don't like the "far from the code" aspect of runtime_info
(or even the static info in some cases).

Another counter argument is perhaps that people are more likely to
update the info for new platforms if it's in a central location, as
opposed having to trawl the entire codebase.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-12 17:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09 22:35 [PATCH 1/4] drm/i915: Store gen_mask inside the static device info Chris Wilson
2018-02-09 22:35 ` [PATCH 2/4] drm/i915: Always define GEN as part of GENx_FEATURES Chris Wilson
2018-02-14 22:40   ` Rodrigo Vivi
2018-02-09 22:35 ` [PATCH 3/4] drm/i915: Store platform_mask inside the static device info Chris Wilson
2018-02-14 22:45   ` Rodrigo Vivi
2018-02-15  7:55     ` Chris Wilson
2018-02-09 22:35 ` [PATCH 4/4] drm/i915: Disable dynamic setup of device_info->num_rings Chris Wilson
2018-02-09 23:46   ` Oscar Mateo
2018-02-10  8:39     ` Chris Wilson
2018-02-12 17:48       ` Ville Syrjälä [this message]
2018-02-09 23:13 ` ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Store gen_mask inside the static device info Patchwork
2018-02-10  0:24 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-02-12  9:58 ` [PATCH 1/4] " Jani Nikula
2018-02-12 10:05   ` Chris Wilson
2018-02-14 22:39 ` Rodrigo Vivi

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=20180212174806.GV5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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