public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Egbert Eich <eich@freedesktop.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 3/8] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check
Date: Tue, 6 Oct 2015 10:23:24 +0200	[thread overview]
Message-ID: <20151006082324.GP3383@phenom.ffwll.local> (raw)
In-Reply-To: <20151002160356.GA8621@sunxi.fritz.box>

On Fri, Oct 02, 2015 at 06:03:57PM +0200, Egbert Eich wrote:
> Regarding commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b
> 
> On Wed, Jul 01, 2015 at 07:25:56PM -0700, Matt Roper wrote:
> > Determine whether we need to apply this workaround at atomic check time
> > and just set a flag that will be used by the main watermark update
> > routine.
> > 
> > Moving this workaround into the atomic framework reduces
> > ilk_update_sprite_wm() to just a standard watermark update, so drop it
> > completely and just ensure that ilk_update_wm() is called whenever a
> > sprite plane is updated in a way that would affect watermarks.
> > 
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> 
> 
> This patch causes intel_update_watermarks() to be called much more
> frequently although the watermark values don't change. 
> The change responsible for this is:
> 
> > index 5de1ded..46ef981 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11560,23 +11560,38 @@ retry:
> >  static bool intel_wm_need_update(struct drm_plane *plane,
> >  				 struct drm_plane_state *state)
> >  {
> > -	/* Update watermarks on tiling changes. */
> > +	struct intel_plane_state *new = to_intel_plane_state(state);
> > +	struct intel_plane_state *cur = to_intel_plane_state(plane->state);
> > +
> > +	/* Update watermarks on tiling or size changes. */
> >  	if (!plane->state->fb || !state->fb ||
> >  	    plane->state->fb->modifier[0] != state->fb->modifier[0] ||
> > -	    plane->state->rotation != state->rotation)
> > -		return true;
> > -
> 
> > -	if (plane->state->crtc_w != state->crtc_w)
> 
> A quick look thru intel_pm.c reveals that this is  relevant for
> WM caluclations for gen=4 and any chipsets for which is_g4x is true.
> Should this really be removed?
> 
> > +	    plane->state->rotation != state->rotation ||
> 
> > +	    drm_rect_width(&new->src) != drm_rect_width(&cur->src) ||
> > +	    drm_rect_height(&new->src) != drm_rect_height(&cur->src) ||
> > +	    drm_rect_width(&new->dst) != drm_rect_width(&cur->dst) ||
> > +	    drm_rect_height(&new->dst) != drm_rect_height(&cur->dst))
> 
> these values seem to be used only for watermark calculations on gen < 9 when
> HAS_PCH_SPLIT() is true.
> 
> Still these are responsible for most of the watermark recalculations (when the mouse
> cursor is moved towards the edge for example). On the system I'm looking at the moment
> (Q35) changes in these values don't change the WMs.
> 
> Since WM calculation is very chip generation specific and differs considerably between
> generations, wouldn't it make sense to either have chipset specific functions to determin
> whether a recalculation is needed - or even perfrom this in the update_wm() function
> itself?

The chipset-specific functions to recalc wm values should check for any
real changes and no-op out if none of the registers have changed. The idea
is that wm calculations are really complex and trying to keep both the "do
we need to recalc" and the actual calculations perfectly in sync is a hard
problem. Hence why we recalc aggressively to avoid hard-to-find bugs where
wm values are stale. So overhead should be just a bit of wasted cpu time.
Do you see bad things happening because of all these recalculations?

I guess if it's real trouble we can make a special case for cursors on
pre-gen9 on plane window changes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-10-06  8:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02  2:25 [RFC 0/8] Atomic watermark updates (v2) Matt Roper
2015-07-02  2:25 ` [RFC 1/8] drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code Matt Roper
2015-07-02  2:25 ` [RFC 2/8] drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM Matt Roper
2015-07-02  2:25 ` [RFC 3/8] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check Matt Roper
2015-10-02 16:03   ` Egbert Eich
2015-10-06  8:23     ` Daniel Vetter [this message]
2015-07-02  2:25 ` [RFC 4/8] drm/i915: Refactor ilk_update_wm (v3) Matt Roper
2015-07-02  2:25 ` [RFC 5/8] drm/i915: Move active watermarks into CRTC state Matt Roper
2015-07-20  9:19   ` Maarten Lankhorst
2015-07-02  2:25 ` [RFC 6/8] drm/i915: Calculate ILK-style watermarks during atomic check (v2) Matt Roper
2015-07-06  9:13   ` Daniel Vetter
2015-07-02  2:26 ` [RFC 7/8] drm/i915: Allow final wm programming to be scheduled after next vblank (v2) Matt Roper
2015-07-06  9:07   ` Daniel Vetter
2015-07-06 11:23     ` Ville Syrjälä
2015-07-20  8:10   ` Maarten Lankhorst
2015-07-02  2:26 ` [RFC 8/8] drm/i915: Add two-stage ILK-style watermark programming (v2) Matt Roper
2015-07-06  9:11   ` Daniel Vetter
2015-07-06 12:20   ` Maarten Lankhorst
2015-07-06 12:26     ` Daniel Vetter

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=20151006082324.GP3383@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=eich@freedesktop.org \
    --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