Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Murthy, Arun R" <arun.r.murthy@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/6] drm/i915: Reject async flips if we need to change DDB/watermarks
Date: Fri, 19 Apr 2024 19:25:34 +0300	[thread overview]
Message-ID: <ZiKa_tyF0USsa2dH@intel.com> (raw)
In-Reply-To: <IA0PR11MB73072BC8E9CEAB07BA6D7E04BA0D2@IA0PR11MB7307.namprd11.prod.outlook.com>

On Fri, Apr 19, 2024 at 04:27:53AM +0000, Murthy, Arun R wrote:
> 
> > -----Original Message-----
> > From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Ville
> > Syrjala
> > Sent: Wednesday, March 20, 2024 9:34 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [PATCH 2/6] drm/i915: Reject async flips if we need to change
> > DDB/watermarks
> > 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > DDB/watermarks are always double buffered on the vblank, so we can't safely
> > change them during async flips. Currently this never happens, but we'll be
> > making changing between sync and async flips a bit more flexible, in which case
> > we can actually end up here.
> 
> Rather on getting wm/DDB changes should we switch from async to sync flip to honour the wm/DDB changes else might end up in underrun or flicker/corruption.
> Spec is also aligned to this approach.

I can't really parse what you're saying.

The sequence of events that can lead us here are:
1. start in sync flip mode
2. userspace asks for an async flip (potentially asking for a
   different modifier)
   - we convert it to a sync flip and proceed
3. userspace asks for another async flip
   either:
   - the format/modifier (and thus wm/ddb) stays the same all
     is good and we do the async flip
   - the modifier changes we will now reject the request due to
     wm/ddb needing to change

We don't want to convert step 3 also to a sync flip because userspace
could just keep pingponging between two buffers with different modifiers
and we'd never actually get into proper async flip mode, and would just
keep doing sync flips. That would completely defat the purpose of async
flips.

And we do have to reject the request here in the wm code because
otherwise we'll clear the do_async_flip flag and the later
intel_async_flip_check_hw() wouldn't refuse the request even though
the modifier is changing. The other option would be to move some/all
of intel_async_flip_check_hw() into some earlier phase of
atomic_check(), but that would require some actual thought.


> Thanks and Regards,
> Arun R Murthy
> --------------------
> 
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/skl_watermark.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> > b/drivers/gpu/drm/i915/display/skl_watermark.c
> > index bc341abcab2f..1fa416a70d51 100644
> > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > @@ -2540,6 +2540,12 @@ skl_ddb_add_affected_planes(const struct
> > intel_crtc_state *old_crtc_state,
> >  					&new_crtc_state-
> > >wm.skl.plane_ddb_y[plane_id]))
> >  			continue;
> > 
> > +		if (new_crtc_state->do_async_flip) {
> > +			drm_dbg_kms(&i915->drm, "[PLANE:%d:%s] Can't
> > change DDB during async flip\n",
> > +				    plane->base.base.id, plane->base.name);
> > +			return -EINVAL;
> > +		}
> > +
> >  		plane_state = intel_atomic_get_plane_state(state, plane);
> >  		if (IS_ERR(plane_state))
> >  			return PTR_ERR(plane_state);
> > @@ -2906,6 +2912,12 @@ static int skl_wm_add_affected_planes(struct
> > intel_atomic_state *state,
> >  						 &new_crtc_state-
> > >wm.skl.optimal))
> >  			continue;
> > 
> > +		if (new_crtc_state->do_async_flip) {
> > +			drm_dbg_kms(&i915->drm, "[PLANE:%d:%s] Can't
> > change watermarks during async flip\n",
> > +				    plane->base.base.id, plane->base.name);
> > +			return -EINVAL;
> > +		}
> > +
> >  		plane_state = intel_atomic_get_plane_state(state, plane);
> >  		if (IS_ERR(plane_state))
> >  			return PTR_ERR(plane_state);
> > --
> > 2.43.2
> 

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2024-04-19 16:25 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20 16:04 [PATCH 0/6] drm/i915: Allow the first async flip to change modifier Ville Syrjala
2024-03-20 16:04 ` [PATCH 1/6] drm/i915: Align PLANE_SURF to 16k on ADL for async flips Ville Syrjala
2024-04-19  4:20   ` Murthy, Arun R
2024-04-19 16:08     ` Ville Syrjälä
2024-04-23  3:36       ` Murthy, Arun R
2024-03-20 16:04 ` [PATCH 2/6] drm/i915: Reject async flips if we need to change DDB/watermarks Ville Syrjala
2024-04-19  4:27   ` Murthy, Arun R
2024-04-19 16:25     ` Ville Syrjälä [this message]
2024-04-23  3:45       ` Murthy, Arun R
2024-04-19  6:31   ` Kulkarni, Vandita
2024-03-20 16:04 ` [PATCH 3/6] drm/i915: Allow the initial async flip to change modifier Ville Syrjala
2024-04-18 16:11   ` Kulkarni, Vandita
2024-03-20 16:04 ` [PATCH 4/6] drm/i915: Eliminate extra frame from skl-glk sync->async flip change Ville Syrjala
2024-04-19  6:39   ` Murthy, Arun R
2024-04-19 16:41     ` Ville Syrjälä
2024-04-23  3:47       ` Murthy, Arun R
2024-03-20 16:04 ` [PATCH 5/6] drm/i915: s/need_async_flip_disable_wa/need_async_flip_toggle_wa/ Ville Syrjala
2024-04-19  6:41   ` Murthy, Arun R
2024-03-20 16:04 ` [PATCH 6/6] drm/i915: Extract ilk_must_disable_lp_wm() Ville Syrjala
2024-04-19  6:54   ` Murthy, Arun R
2024-03-21  1:05 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Allow the first async flip to change modifier Patchwork
2024-03-21  1:18 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-21 11:43 ` ✗ Fi.CI.IGT: 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=ZiKa_tyF0USsa2dH@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=arun.r.murthy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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