Intel-XE Archive on lore.kernel.org
 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, 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

  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