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
next prev parent 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).