All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Zanoni <przanoni@gmail.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: Minimize the huge amount of unecessary fbc sw cache clean.
Date: Thu, 25 Sep 2014 14:48:19 -0300	[thread overview]
Message-ID: <CA+gsUGQ1BC1LCFeosb5oVN_Le0kP969KrhhCBaCKY=WMJkVU8Q@mail.gmail.com> (raw)
In-Reply-To: <1411602659-1897-1-git-send-email-rodrigo.vivi@intel.com>

2014-09-24 20:50 GMT-03:00 Rodrigo Vivi <rodrigo.vivi@intel.com>:
> The sw cache clean on BDW is a tempoorary workaround because we cannot
> set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw.
> However we are doing much more than needed. Not only when using blt ring.
> So, with this extra w/a we minimize the ammount of cache cleans and call it only
> on same cases that it was being called on gen7.
>
> The traditional FBC Cache clean happens over LRI on BLT ring when there is a
> frontbuffer touch happening. frontbuffer tracking set fbc_dirty variable
> to let BLT flush that it must clean FBC cache.
>
> fbc.need_sw_cache_clean works in the opposite information direction
> of ring->fbc_dirty telling software on frontbuffer tracking to perform
> the cache clean on sw side.
>
> v2: Clean it a little bit and fully check for Broadwell instead of gen8.
>
> v3: Rebase after frontbuffer organization.
>
> v4: Wiggle confused me. So fixing v3!
>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h          | 10 +++++++++-
>  drivers/gpu/drm/i915/intel_frontbuffer.c |  6 ++++--
>  drivers/gpu/drm/i915/intel_pm.c          |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  9 +++++++--
>  4 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index da607ab..4cd2aa3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -676,6 +676,14 @@ struct i915_fbc {
>          * possible. */
>         bool enabled;
>
> +       /* On gen8 some rings cannont perform fbc clean operation so for now
> +        * we are doing this on SW with mmio.
> +        * This variable works in the opposite information direction
> +        * of ring->fbc_dirty telling software on frontbuffer tracking
> +        * to perform the cache clean on sw side.
> +        */
> +       bool need_sw_cache_clean;
> +
>         struct intel_fbc_work {
>                 struct delayed_work work;
>                 struct drm_crtc *crtc;
> @@ -2843,7 +2851,7 @@ extern void intel_modeset_setup_hw_state(struct drm_device *dev,
>  extern void i915_redisable_vga(struct drm_device *dev);
>  extern void i915_redisable_vga_power_on(struct drm_device *dev);
>  extern bool intel_fbc_enabled(struct drm_device *dev);
> -extern void gen8_fbc_sw_flush(struct drm_device *dev, u32 value);
> +extern void bdw_fbc_sw_flush(struct drm_device *dev, u32 value);
>  extern void intel_disable_fbc(struct drm_device *dev);
>  extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
>  extern void intel_init_pch_refclk(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index f74744c..7eb74a6 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -189,8 +189,10 @@ void intel_frontbuffer_flush(struct drm_device *dev,
>          * needs to be reworked into a proper frontbuffer tracking scheme like
>          * psr employs.
>          */
> -       if (IS_BROADWELL(dev))
> -               gen8_fbc_sw_flush(dev, FBC_REND_CACHE_CLEAN);
> +       if (dev_priv->fbc.need_sw_cache_clean) {

In your first version, you had removed this IS_BROADWELL check, but
you replaced the check inside bdw_fbc_sw_flush() from IS_GEN8 to
IS_BROADWELL.


> +               dev_priv->fbc.need_sw_cache_clean = false;
> +               bdw_fbc_sw_flush(dev, FBC_REND_CACHE_CLEAN);
> +       }
>  }
>
>  /**
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index aaab056..36842c4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -380,7 +380,7 @@ bool intel_fbc_enabled(struct drm_device *dev)
>         return dev_priv->fbc.enabled;
>  }
>
> -void gen8_fbc_sw_flush(struct drm_device *dev, u32 value)
> +void bdw_fbc_sw_flush(struct drm_device *dev, u32 value)
>  {
>         struct drm_i915_private *dev_priv = dev->dev_private;
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 896f564..b56e031 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2237,6 +2237,7 @@ static int gen6_ring_flush(struct intel_engine_cs *ring,
>                            u32 invalidate, u32 flush)
>  {
>         struct drm_device *dev = ring->dev;
> +       struct drm_i915_private *dev_priv = dev->dev_private;
>         uint32_t cmd;
>         int ret;
>
> @@ -2267,8 +2268,12 @@ static int gen6_ring_flush(struct intel_engine_cs *ring,
>         }
>         intel_ring_advance(ring);
>
> -       if (IS_GEN7(dev) && !invalidate && flush)
> -               return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN);
> +       if (!invalidate && flush) {
> +               if (IS_GEN7(dev))
> +                       return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN);
> +               else if (IS_BROADWELL(dev))
> +                       dev_priv->fbc.need_sw_cache_clean = true;

OTOH, since we'll only ever set need_sw_cache_clean on BDW because of
the check above, this version cannot be considered wrong, just
different from the previous one.

If I were to write this patch, I would unconditionally set
need_sw_cache_clean on all platforms, and then change the check inside
bdw_fbc_sw_flush() to return if the platform is not BDW. But your
patch is correct, so:

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

> +       }
>
>         return 0;
>  }
> --
> 1.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni

  reply	other threads:[~2014-09-25 17:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 20:57 [PATCH 1/2] drm/i915: Only flush fbc on sw when fbc is enabled Rodrigo Vivi
2014-09-05 20:57 ` [PATCH 2/2] drm/i915: Minimize the huge amount of unecessary fbc sw cache clean Rodrigo Vivi
2014-09-05 22:14   ` Rodrigo Vivi
2014-09-17 20:36     ` Rodrigo Vivi
2014-09-17 20:49   ` Paulo Zanoni
2014-09-17 21:16     ` Rodrigo Vivi
2014-09-18 15:29       ` [PATCH] " Rodrigo Vivi
2014-09-19 16:32         ` Paulo Zanoni
2014-09-24 23:11           ` Rodrigo Vivi
2014-09-24 23:50             ` Rodrigo Vivi
2014-09-25 17:48               ` Paulo Zanoni [this message]
2014-09-29 12:17               ` Daniel Vetter
2014-09-17 19:55 ` [PATCH 1/2] drm/i915: Only flush fbc on sw when fbc is enabled Paulo Zanoni

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='CA+gsUGQ1BC1LCFeosb5oVN_Le0kP969KrhhCBaCKY=WMJkVU8Q@mail.gmail.com' \
    --to=przanoni@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=rodrigo.vivi@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.