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, jouni.hogander@intel.com
Subject: Re: [PATCH v3 1/4] drm/i915/display: avoid calling fbc activate if fbc is active
Date: Fri, 17 Jan 2025 14:49:04 +0200 [thread overview]
Message-ID: <Z4pRwB6mkTDNMAEu@intel.com> (raw)
In-Reply-To: <20250114120719.191372-2-vinod.govindapillai@intel.com>
On Tue, Jan 14, 2025 at 02:07:16PM +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.
> "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 followup patches. Nuke on flip in that case will
> remove all the benefits of fetching only the modified region.
>
> 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 | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index df05904bac8a..fd540ff5e57e 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1561,7 +1561,8 @@ static void __intel_fbc_post_update(struct intel_fbc *fbc)
> fbc->flip_pending = false;
> fbc->busy_bits = 0;
>
> - intel_fbc_activate(fbc);
> + if (!fbc->active)
> + intel_fbc_activate(fbc);
We'll need to keep the actual activate part (eg. to update the fence).
But we should be able to elide the explicit nuke if FBC was already
active (that implies a flip nuke has occurred anyway, vs. if FBC was
previously disabled then it might have been disabled by a frontbuffer
invalidate and if it hasn't been disabled for a full frame then the
hardware won't automagically cause a nuke when we reactivate it).
> }
>
> void intel_fbc_post_update(struct intel_atomic_state *state,
> --
> 2.43.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-01-17 12:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-14 12:07 [PATCH v3 0/4] drm/i915/xe3: FBC Dirty rect feature support Vinod Govindapillai
2025-01-14 12:07 ` [PATCH v3 1/4] drm/i915/display: avoid calling fbc activate if fbc is active Vinod Govindapillai
2025-01-17 12:49 ` Ville Syrjälä [this message]
2025-01-21 8:55 ` Govindapillai, Vinod
2025-01-14 12:07 ` [PATCH v3 2/4] drm/i915/xe: add register definitions for fbc dirty rect support Vinod Govindapillai
2025-01-14 12:07 ` [PATCH v3 3/4] drm/i915/xe3: add dirty rect support for FBC Vinod Govindapillai
2025-01-17 13:00 ` Ville Syrjälä
2025-01-14 12:07 ` [PATCH v3 4/4] drm/i915/xe3: disable FBC if PSR2 selective fetch is enabled Vinod Govindapillai
2025-01-14 12:14 ` ✓ CI.Patch_applied: success for drm/i915/xe3: FBC Dirty rect feature support (rev3) Patchwork
2025-01-14 12:14 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-14 12:16 ` ✓ CI.KUnit: success " Patchwork
2025-01-14 12:44 ` ✓ CI.Build: " Patchwork
2025-01-14 12:46 ` ✓ CI.Hooks: " Patchwork
2025-01-14 12:48 ` ✗ CI.checksparse: warning " Patchwork
2025-01-14 13:15 ` ✓ Xe.CI.BAT: success " Patchwork
2025-01-14 16:23 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-21 11:49 ` ✗ CI.Patch_applied: failure for drm/i915/xe3: FBC Dirty rect feature support (rev4) 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=Z4pRwB6mkTDNMAEu@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=jouni.hogander@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