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,
dri-devel@lists.freedesktop.org, ville.syrjala@intel.com,
santhosh.reddy.guddati@intel.com, jani.saarinen@intel.com
Subject: Re: [PATCH v7 5/7] drm/i915/xe3: avoid calling fbc activate if fbc is active
Date: Wed, 12 Feb 2025 20:30:00 +0200 [thread overview]
Message-ID: <Z6zoqILXcOM0YKEc@intel.com> (raw)
In-Reply-To: <20250212131420.60026-6-vinod.govindapillai@intel.com>
On Wed, Feb 12, 2025 at 03:14:18PM +0200, Vinod Govindapillai wrote:
> If FBC is already active, we don't need to call FBC activate
> routine again. This is more relevant in case of dirty rect
> support in FBC. Xe doesn't support legacy fences. Hence fence
> programming also not required as part of this fbc_hw_activate.
> Any FBC related register updates done after enabling the dirty
> rect support in xe3 will trigger nuke by FBC HW. So avoid
> calling fbc activate routine again if the FBC is already active.
>
> 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.
>
> v2: use HAS_FBC_DIRTY_RECT()
> move this functionality within intel_fbc_activate()
>
> 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..951dc81b7b97 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -739,8 +739,19 @@ static void intel_fbc_nuke(struct intel_fbc *fbc)
>
> static void intel_fbc_activate(struct intel_fbc *fbc)
> {
> + struct intel_display *display = fbc->display;
> +
> lockdep_assert_held(&fbc->lock);
>
> + /*
> + * 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.
I have no idea what XE3 and Xe here mean. I would just state
that platforms which have dirty rect don't have fences.
> + */
> + if (HAS_FBC_DIRTY_RECT(display) && fbc->active)
> + return;
I don't quite like the assumptions being made here.
Since only the fence can change upon flip nuke we should
probably check for intel_fbc_has_fences() instead of
HAS_DIRTY_RECT() and thus just skip this on all platforms
that don't have fences. That also increases our testing
coverage for this short circuit path, which is a good thing.
Ideally I guess we should check if the fence is actually
changing or not, but we don't have the old state around
anymore so can't do it right now.
So I guess we could do something like:
/* only the fence can change for a flip nuke */
if (fbc->active && !has_fences())
return;
/*
* the explanation about the FBC register write
* nuke vs. dirty rect stuff.
*/
drm_WARN_ON(fbc->active && HAS_DIRTY_RECT());
> +
> intel_fbc_hw_activate(fbc);
> intel_fbc_nuke(fbc);
>
> --
> 2.43.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-02-12 18:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 13:14 [PATCH v7 0/7] drm/i915/fbc: FBC Dirty rect feature support Vinod Govindapillai
2025-02-12 13:14 ` [PATCH v7 1/7] drm/damage-helper: add const qualifier in drm_atomic_helper_damage_merged() Vinod Govindapillai
2025-02-12 13:14 ` [PATCH v7 2/7] drm/i915/xe3: update and store the plane damage clips Vinod Govindapillai
2025-02-12 18:35 ` Ville Syrjälä
2025-02-12 20:14 ` Govindapillai, Vinod
2025-02-12 20:42 ` Ville Syrjälä
2025-02-12 13:14 ` [PATCH v7 3/7] drm/i915/xe3: add register definitions for fbc dirty rect support Vinod Govindapillai
2025-02-12 13:14 ` [PATCH v7 4/7] drm/i915/xe3: introduce HAS_FBC_DIRTY_RECT() for FBC " Vinod Govindapillai
2025-02-12 13:14 ` [PATCH v7 5/7] drm/i915/xe3: avoid calling fbc activate if fbc is active Vinod Govindapillai
2025-02-12 18:30 ` Ville Syrjälä [this message]
2025-02-12 20:21 ` Govindapillai, Vinod
2025-02-12 13:14 ` [PATCH v7 6/7] drm/i915/xe3: dirty rect support for FBC Vinod Govindapillai
2025-02-12 18:42 ` Ville Syrjälä
2025-02-12 13:14 ` [PATCH v7 7/7] drm/i915/xe3: disable FBC if PSR2 selective fetch is enabled Vinod Govindapillai
2025-02-12 14:48 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/fbc: FBC Dirty rect feature support Patchwork
2025-02-12 14:48 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-02-12 15:09 ` ✓ i915.CI.BAT: success " Patchwork
2025-02-12 22:37 ` ✗ i915.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=Z6zoqILXcOM0YKEc@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--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