All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/6] drm/i915: Tighten SAGV constraint for pre-tgl
Date: Fri, 12 Mar 2021 14:12:30 +0200	[thread overview]
Message-ID: <20210312121230.GA12252@intel.com> (raw)
In-Reply-To: <YEo3K4RjsgsMSNiZ@intel.com>

On Thu, Mar 11, 2021 at 05:28:43PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 11, 2021 at 04:36:05PM +0200, Lisovskiy, Stanislav wrote:
> > On Fri, Mar 05, 2021 at 05:36:06PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > Say we have two planes enabled with watermarks configured
> > > as follows:
> > > plane A: wm0=enabled/can_sagv=false, wm1=enabled/can_sagv=true
> > > plane B: wm0=enabled/can_sagv=true,  wm1=disabled
> > 
> > Was thinking about this, always thought its not possible, i.e
> > wm1 kinda requires more resources, so if we can do wm1, should
> > always be able to do wm0..
> > 
> > > 
> > > This is possible since the latency we use to calculate
> > > can_sagv may not be the same for both planes due to
> > > skl_needs_memory_bw_wa().
> > 
> > The current code, which I see in internal at least looks like this:
> > 
> > /*
> >  * FIXME: We still don't have the proper code detect if we need to apply the WA,
> >  * so assume we'll always need it in order to avoid underruns.
> >  */
> > static bool skl_needs_memory_bw_wa(struct drm_i915_private *dev_priv)
> > {
> >       return IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv);
> > }
> > 
> > i.e I think it will return same latency for all planes.
> > 
> > Or am I missing something?..
> 
> We do stuff like 
> if (skl_needs_memory_bw_wa(dev_priv) && wp->x_tiled)
> 	latency += 15;
> so different latencies for different tilings.
> 
> Also the fact that eg. Y vs. X/linear do the method1 vs. method2
> selection differently could mean we get different set of wm levels
> even w/o any latency adjustments. Or at least it's impossible for
> me to see from the code that it couldn't happen.

Ah ok, so it is based on tiling basically.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

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

  reply	other threads:[~2021-03-12 12:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 15:36 [Intel-gfx] [PATCH 0/6] drm/i915: More SAGV related fixes/cleanups Ville Syrjala
2021-03-05 15:36 ` [Intel-gfx] [PATCH 1/6] drm/i915: Fix enabled_planes bitmask Ville Syrjala
2021-03-19 21:17   ` Navare, Manasi
2021-03-19 21:20     ` Ville Syrjälä
2021-03-19 21:30       ` Navare, Manasi
2021-03-05 15:36 ` [Intel-gfx] [PATCH 2/6] drm/i915: Tighten SAGV constraint for pre-tgl Ville Syrjala
2021-03-11 14:36   ` Lisovskiy, Stanislav
2021-03-11 15:28     ` Ville Syrjälä
2021-03-12 12:12       ` Lisovskiy, Stanislav [this message]
2021-03-05 15:36 ` [Intel-gfx] [PATCH 3/6] drm/i915: Check SAGV wm min_ddb_alloc rather than plane_res_b Ville Syrjala
2021-03-12 12:13   ` Lisovskiy, Stanislav
2021-03-05 15:36 ` [Intel-gfx] [PATCH 4/6] drm/i915: Calculate min_ddb_alloc for trans_wm Ville Syrjala
2021-03-12 12:14   ` Lisovskiy, Stanislav
2021-03-05 15:36 ` [Intel-gfx] [PATCH 5/6] drm/i915: Extract skl_check_wm_level() and skl_check_nv12_wm_level() Ville Syrjala
2021-03-12 12:25   ` Lisovskiy, Stanislav
2021-03-05 15:36 ` [Intel-gfx] [PATCH 6/6] drm/i915: s/plane_res_b/blocks/ etc Ville Syrjala
2021-03-11 14:26   ` Lisovskiy, Stanislav
2021-03-12 12:45   ` Lisovskiy, Stanislav
2021-03-05 16:22 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: More SAGV related fixes/cleanups Patchwork
2021-03-05 16:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-03-05 20:11 ` [Intel-gfx] ✗ 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=20210312121230.GA12252@intel.com \
    --to=stanislav.lisovskiy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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.