intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Saarinen, Jani" <jani.saarinen@intel.com>,
	"Reddy Guddati, Santhosh" <santhosh.reddy.guddati@intel.com>,
	"Syrjala, Ville" <ville.syrjala@intel.com>
Subject: Re: [PATCH v4 5/6] drm/i915/xe3: handle dirty rect update within the scope of DSB
Date: Thu, 23 Jan 2025 11:46:43 +0200	[thread overview]
Message-ID: <87wmeln9q4.fsf@intel.com> (raw)
In-Reply-To: <f13004f739a71883e033bf1fd89af6999202cf67.camel@intel.com>

On Wed, 22 Jan 2025, "Govindapillai, Vinod" <vinod.govindapillai@intel.com> wrote:
> On Wed, 2025-01-22 at 12:47 +0200, Jani Nikula wrote:
>> On Wed, 22 Jan 2025, Vinod Govindapillai <vinod.govindapillai@intel.com> wrote:
>> > Programming of the dirty rectangle coordinates should happen
>> > within the scope of DSB prepare and finish calls. So call the
>> > compute and programming of dirty rectangle related routines
>> > early within the DSB programming window. Some of the FBC state
>> > handling is done later as part of pre-plane or post-plane
>> > updates. So enabling / disabling / hw activate will happen
>> > later but it should handle the sequence without any issue.
>> > 
>> > Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_display.c |  3 ++
>> >  drivers/gpu/drm/i915/display/intel_fbc.c     | 47 ++++++++++++++++----
>> >  drivers/gpu/drm/i915/display/intel_fbc.h     |  3 ++
>> >  3 files changed, 44 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> > b/drivers/gpu/drm/i915/display/intel_display.c
>> > index d154fcd0e77a..e6e017e65da6 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -7773,6 +7773,9 @@ static void intel_atomic_commit_tail(struct intel_atomic_state *state)
>> >  
>> >  	intel_atomic_prepare_plane_clear_colors(state);
>> >  
>> > +	for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
>> > +		intel_fbc_compute_dirty_rect(state, crtc);
>> 
>> "compute" is a fairly loaded word in our driver. The immediate
>> association is "it's compute config, but missing the config part". And
>> doing anything "compute" seems completely out of place in
>> intel_atomic_commit_tail(), where we've long since passed the compute
>> config stage.
>
> Well.. actually I dont need this call at all. I don't need to split this between compute_dirt_rect
> and program_dirty_rect. Instead I can directly call program_dirty rect which internally gets the
> dirty rects. I will update that
>
>> 
>> > +
>> >  	for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
>> >  		intel_atomic_dsb_finish(state, crtc);
>> >  
>> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
>> > index 963fbe2c7361..033eb4a3eab0 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>> > @@ -1213,6 +1213,10 @@ static bool tiling_is_valid(const struct intel_plane_state *plane_state)
>> >  		return i8xx_fbc_tiling_valid(plane_state);
>> >  }
>> >  
>> > +static bool intel_fbc_can_flip_nuke(struct intel_atomic_state *state,
>> > +				    struct intel_crtc *crtc,
>> > +				    struct intel_plane *plane);
>> > +
>> >  static void
>> >  __intel_fbc_program_dirty_rect(struct intel_dsb *dsb, struct intel_plane *plane)
>> >  {
>> > @@ -1251,7 +1255,6 @@ intel_fbc_program_dirty_rect(struct intel_dsb *dsb,
>> >  	}
>> >  }
>> >  
>> > -
>> 
>> The previous patch added a superfluous newline here, and this one
>> removes it. Please just don't add it in the first place.
>
> Yeah.. not really intentional. I will update!
> My local checkpatch didn't catch that though! But the CI checkpatch did.

Try with:

scripts/checkpatch.pl -q --emacs --strict --show-types --max-line-length=100 --ignore=BIT_MACRO,SPLIT_STRING,LONG_LINE_STRING,BOOL_MEMBER


>
> BR
> Vinod
>
>> 
>> >  static void
>> >  update_dirty_rect_to_full_region(struct intel_plane_state *plane_state,
>> >  				 struct drm_rect *dirty_rect)
>> > @@ -1276,9 +1279,9 @@ validate_and_clip_dirty_rect(struct intel_plane_state *plane_state,
>> >  }
>> >  
>> >  static void
>> > -intel_fbc_compute_dirty_rect(struct intel_plane *plane,
>> > -			     struct intel_plane_state *old_plane_state,
>> > -			     struct intel_plane_state *new_plane_state)
>> > +__intel_fbc_compute_dirty_rect(struct intel_plane *plane,
>> > +			       struct intel_plane_state *old_plane_state,
>> > +			       struct intel_plane_state *new_plane_state)
>> >  {
>> >  	struct intel_fbc *fbc = plane->fbc;
>> >  	struct intel_fbc_state *fbc_state = &fbc->state;
>> > @@ -1292,6 +1295,37 @@ intel_fbc_compute_dirty_rect(struct intel_plane *plane,
>> >  		update_dirty_rect_to_full_region(new_plane_state, fbc_dirty_rect);
>> >  }
>> >  
>> > +void
>> > +intel_fbc_compute_dirty_rect(struct intel_atomic_state *state,
>> > +			     struct intel_crtc *crtc)
>> > +{
>> > +	struct intel_display *display = to_intel_display(state);
>> > +	struct intel_plane_state *new_plane_state;
>> > +	struct intel_plane_state *old_plane_state;
>> > +	struct intel_plane *plane;
>> > +	int i;
>> > +
>> > +	if (DISPLAY_VER(display) < 30)
>> > +		return;
>> > +
>> > +	for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state, new_plane_state, i)
>> > {
>> > +		struct intel_fbc *fbc = plane->fbc;
>> > +
>> > +		if (!fbc || plane->pipe != crtc->pipe)
>> > +			continue;
>> > +
>> > +		/* If plane not visible, dirty rect might have invalid coordinates */
>> > +		if (!new_plane_state->uapi.visible)
>> > +			continue;
>> > +
>> > +		/* If FBC to be disabled, then no need to update dirty rect */
>> > +		if (!intel_fbc_can_flip_nuke(state, crtc, plane))
>> > +			continue;
>> > +
>> > +		__intel_fbc_compute_dirty_rect(plane, old_plane_state, new_plane_state);
>> > +	}
>> > +}
>> > +
>> >  static void intel_fbc_update_state(struct intel_atomic_state *state,
>> >  				   struct intel_crtc *crtc,
>> >  				   struct intel_plane *plane)
>> > @@ -1301,8 +1335,6 @@ static void intel_fbc_update_state(struct intel_atomic_state *state,
>> >  		intel_atomic_get_new_crtc_state(state, crtc);
>> >  	struct intel_plane_state *plane_state =
>> >  		intel_atomic_get_new_plane_state(state, plane);
>> > -	struct intel_plane_state *old_plane_state =
>> > -		intel_atomic_get_old_plane_state(state, plane);
>> >  	struct intel_fbc *fbc = plane->fbc;
>> >  	struct intel_fbc_state *fbc_state = &fbc->state;
>> >  
>> > @@ -1327,9 +1359,6 @@ static void intel_fbc_update_state(struct intel_atomic_state *state,
>> >  	fbc_state->cfb_stride = intel_fbc_cfb_stride(plane_state);
>> >  	fbc_state->cfb_size = intel_fbc_cfb_size(plane_state);
>> >  	fbc_state->override_cfb_stride = intel_fbc_override_cfb_stride(plane_state);
>> > -
>> > -	if (DISPLAY_VER(display) >= 30)
>> > -		intel_fbc_compute_dirty_rect(plane, old_plane_state, plane_state);
>> >  }
>> >  
>> >  static bool intel_fbc_is_fence_ok(const struct intel_plane_state *plane_state)
>> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h b/drivers/gpu/drm/i915/display/intel_fbc.h
>> > index acaebe15f312..87be5653db0f 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_fbc.h
>> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.h
>> > @@ -49,8 +49,11 @@ void intel_fbc_handle_fifo_underrun_irq(struct intel_display *display);
>> >  void intel_fbc_reset_underrun(struct intel_display *display);
>> >  void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc);
>> >  void intel_fbc_debugfs_register(struct intel_display *display);
>> > +void intel_fbc_compute_dirty_rect(struct intel_atomic_state *state,
>> > +				  struct intel_crtc *crtc);
>> >  void intel_fbc_program_dirty_rect(struct intel_dsb *dsb,
>> >  				  struct intel_atomic_state *state,
>> >  				  struct intel_crtc *crtc);
>> >  
>> > +
>> 
>> Superfluous newline.
>> 
>> >  #endif /* __INTEL_FBC_H__ */
>> 
>

-- 
Jani Nikula, Intel

  reply	other threads:[~2025-01-23  9:46 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ä
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 [this message]
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=87wmeln9q4.fsf@intel.com \
    --to=jani.nikula@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).