intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	ville.syrjala@intel.com, santhosh.reddy.guddati@intel.com,
	jani.saarinen@intel.com
Subject: Re: [PATCH v4 1/6] drm/i915/xe3: avoid calling fbc activate if fbc is active
Date: Wed, 22 Jan 2025 20:13:49 +0200	[thread overview]
Message-ID: <Z5E1XQuNBKnLn8jg@intel.com> (raw)
In-Reply-To: <20250122093006.405711-2-vinod.govindapillai@intel.com>

On Wed, Jan 22, 2025 at 11:30:01AM +0200, Vinod Govindapillai wrote:
> If FBC is already active, we don't need to call FBC activate
> routine again during the post plane update. As this will
> explicitly call the nuke and also rewrite the FBC ctl registers.
> Xe doesn't support legacy fences. Hence fence programming also
> not required as part of this fbc_haw_activate.
> 
> "intel_atomic_commit_tail-> intel_post_plane_update->
> intel_fbc_post_update-> _intel_fbc_post_update" path will be
> executed during the normal flip cases. FBC HW will nuke on sync
> flip event and driver do not need to call the nuke explicitly.
> 
> This is much more relevant in case of dirty rectangle support
> in FBC with the follow-up patches. Nuke on flip in that case will
> remove all the benefits of fetching only the modified region.
> Also any FBC related register updates with dirty rectangle
> support enabled will trigger nuke by FBC HW.
> 
> The front buffer rendering sequence will call intel_fbc_flush()
> and which will call intel_fbc_nuke() or intel_fbc_activate()
> based on FBC status explicitly and won't get impacted by this
> change.
> 
> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index df05904bac8a..ab9649dd606c 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1556,11 +1556,22 @@ static void __intel_fbc_disable(struct intel_fbc *fbc)
>  
>  static void __intel_fbc_post_update(struct intel_fbc *fbc)
>  {
> +	struct intel_display *display = fbc->display;
> +
>  	lockdep_assert_held(&fbc->lock);
>  
>  	fbc->flip_pending = false;
>  	fbc->busy_bits = 0;
>  
> +	/*
> +	 * When dirty rectangle is enabled, any updates to FBC registers will
> +	 * trigger nuke. So avoid calling intel_fbc_activate if fbc is already
> +	 * active and for XE3 cases. Xe doesn't support legacy fences. So
> +	 * no need to update the fences as well.
> +	 */
> +	if (DISPLAY_VER(display) >= 30 && fbc->active)
> +		return;

Don't like platform checks in generic code. Either we should 
skip the stride programming inside the hw specific function,
or we pull the strie programming into a separate hook which
we can then skip completely when FBC was already active.

> +
>  	intel_fbc_activate(fbc);
>  }
>  
> -- 
> 2.43.0

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-01-22 18:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22  9:30 [PATCH v4 0/6] drm/i915/xe3: FBC Dirty rect feature support Vinod Govindapillai
2025-01-22  9:30 ` [PATCH v4 1/6] drm/i915/xe3: avoid calling fbc activate if fbc is active Vinod Govindapillai
2025-01-22 18:13   ` Ville Syrjälä [this message]
2025-01-22 18:31     ` Govindapillai, Vinod
2025-01-22  9:30 ` [PATCH v4 2/6] drm/i915/xe3: add register definitions for fbc dirty rect support Vinod Govindapillai
2025-01-22  9:30 ` [PATCH v4 3/6] drm/i915/xe3: disable FBC if PSR2 selective fetch is enabled Vinod Govindapillai
2025-01-22  9:30 ` [PATCH v4 4/6] drm/i915/xe3: add dirty rect support for FBC Vinod Govindapillai
2025-01-22 10:39   ` Jani Nikula
2025-01-22 19:41   ` Ville Syrjälä
2025-01-22  9:30 ` [PATCH v4 5/6] drm/i915/xe3: handle dirty rect update within the scope of DSB Vinod Govindapillai
2025-01-22 10:47   ` Jani Nikula
2025-01-22 13:55     ` Govindapillai, Vinod
2025-01-23  9:46       ` Jani Nikula
2025-01-22  9:30 ` [PATCH v4 6/6] drm/i915/xe3: introduce a dirty rectangle state variable Vinod Govindapillai
2025-01-22 10:42   ` Jani Nikula
2025-01-22 11:36 ` ✓ CI.Patch_applied: success for drm/i915/xe3: FBC Dirty rect feature support (rev5) Patchwork
2025-01-22 11:37 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-22 11:38 ` ✓ CI.KUnit: success " Patchwork
2025-01-22 11:54 ` ✓ CI.Build: " Patchwork
2025-01-22 11:56 ` ✓ CI.Hooks: " Patchwork
2025-01-22 11:58 ` ✗ CI.checksparse: warning " Patchwork
2025-01-22 12:25 ` ✓ Xe.CI.BAT: success " Patchwork
2025-01-22 22:46 ` ✗ Xe.CI.Full: 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=Z5E1XQuNBKnLn8jg@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.saarinen@intel.com \
    --cc=santhosh.reddy.guddati@intel.com \
    --cc=ville.syrjala@intel.com \
    --cc=vinod.govindapillai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).