All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 05/13] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck
Date: Tue, 16 May 2023 13:11:50 +0300	[thread overview]
Message-ID: <ZGNWnP1/vWckkAkA@intel.com> (raw)
In-Reply-To: <ZGJFYziCKeW-vfpF@intel.com>

On Mon, May 15, 2023 at 05:44:51PM +0300, Ville Syrjälä wrote:
> On Fri, May 12, 2023 at 11:54:09AM +0530, Ankit Nautiyal wrote:
> > As per Bsepc:49259, Bigjoiner BW check puts restriction on the
> > compressed bpp for a given CDCLK, pixelclock in cases where
> > Bigjoiner + DSC are used.
> > 
> > Currently compressed bpp is computed first, and it is ensured that
> > the bpp will work at least with the max CDCLK freq.
> > 
> > Since the CDCLK is computed later, lets account for Bigjoiner BW
> > check while calculating Min CDCLK.
> > 
> > Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++++++++++++++++++----
> >  1 file changed, 42 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 6bed75f1541a..3532640c5027 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2520,6 +2520,46 @@ static int intel_planes_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  	return min_cdclk;
> >  }
> >  
> > +static int intel_vdsc_min_cdclk(const struct intel_crtc_state *crtc_state)
> > +{
> > +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +	struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +	int min_cdclk = 0;
> > +
> > +	/*
> > +	 * When we decide to use only one VDSC engine, since
> > +	 * each VDSC operates with 1 ppc throughput, pixel clock
> > +	 * cannot be higher than the VDSC clock (cdclk)
> > +	 */
> > +	if (!crtc_state->dsc.dsc_split)
> > +		min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +
> > +	if (crtc_state->bigjoiner_pipes) {
> > +		/*
> > +		 * According to Bigjoiner bw check:
> > +		 * compressed_bpp <= PPC * CDCLK * Big joiner Interface bits / Pixel clock
> > +		 *
> > +		 * We have already computed compressed_bpp, so now compute the min CDCLK that
> > +		 * is required to support this compressed_bpp.
> > +		 *
> > +		 * => CDCLK >= compressed_bpp * Pixel clock / (PPC * Bigjoiner Interface bits)
> > +		 *
> > +		 * Since Num of pipes joined = 2, and PPC = 2 with bigjoiner
> > +		 * => CDCLK >= compressed_bpp * pixel_rate  / Bigjoiner Interface bits
> > +		 *
> > +		 * #TODO Bspec mentions to account for FEC overhead while using pixel clock.
> > +		 * Check if we need to use FEC overhead in the above calculations.
> > +		 */
> > +		int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
> > +		int min_cdclk_bj = crtc_state->dsc.compressed_bpp * crtc_state->pixel_rate /
> > +				   bigjoiner_interface_bits;
> 
> pixel_rate is the downscale adjusted thing, so it doesn't seem
> like the correct thing to use here.
> 
> Hmm. Assuming that the single VDSC engine really throttles the entire
> pipe to 1 PPC then we should probably account for the 1 vs. 2 PPC
> difference in *_plane_min_cdclk() and intel_pixel_rate_to_cdclk()
> directly. Currently all of those assume 2 PPC.

Main thing is to properly align that one you propose above with that check,
where we decide how many VDSC engines to use:

        /*
         * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
         * is greater than the maximum Cdclock and if slice count is even
         * then we need to use 2 VDSC instances.
         */
        if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
                if (pipe_config->dsc.slice_count > 1) {
                        pipe_config->dsc.dsc_split = true;
                } else {
                        drm_dbg_kms(&dev_priv->drm,
                                    "Cannot split stream to use 2 VDSC instances\n");
                        return -EINVAL;
                }
        }

Otherwise I agree that we should do that check preferrably in *_plane_min_cdclk
and use plane data rate which is adjusted after scaling is applied(I think we even have correspondent function there)
It is strange that scaling wasn't mentioned in BSpec formula.
I would also say that we should account for number of slices(i.e VDSC engines) now only in Bigjoiner case, but always, as I understand that number can be different not only for Bigjoiner cases.

Stan


> 
> > +
> > +		min_cdclk = max(min_cdclk, min_cdclk_bj);
> > +	}
> > +
> > +	return min_cdclk;
> > +}
> > +
> >  int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  {
> >  	struct drm_i915_private *dev_priv =
> > @@ -2591,13 +2631,8 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  	/* Account for additional needs from the planes */
> >  	min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> >  
> > -	/*
> > -	 * When we decide to use only one VDSC engine, since
> > -	 * each VDSC operates with 1 ppc throughput, pixel clock
> > -	 * cannot be higher than the VDSC clock (cdclk)
> > -	 */
> > -	if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
> > -		min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +	if (crtc_state->dsc.compression_enable)
> > +		min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
> >  
> >  	/*
> >  	 * HACK. Currently for TGL/DG2 platforms we calculate
> > -- 
> > 2.25.1
> 
> -- 
> Ville Syrjälä
> Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>,
	anusha.srivatsa@intel.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, navaremanasi@google.com
Subject: Re: [PATCH 05/13] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck
Date: Tue, 16 May 2023 13:11:50 +0300	[thread overview]
Message-ID: <ZGNWnP1/vWckkAkA@intel.com> (raw)
In-Reply-To: <ZGJFYziCKeW-vfpF@intel.com>

On Mon, May 15, 2023 at 05:44:51PM +0300, Ville Syrjälä wrote:
> On Fri, May 12, 2023 at 11:54:09AM +0530, Ankit Nautiyal wrote:
> > As per Bsepc:49259, Bigjoiner BW check puts restriction on the
> > compressed bpp for a given CDCLK, pixelclock in cases where
> > Bigjoiner + DSC are used.
> > 
> > Currently compressed bpp is computed first, and it is ensured that
> > the bpp will work at least with the max CDCLK freq.
> > 
> > Since the CDCLK is computed later, lets account for Bigjoiner BW
> > check while calculating Min CDCLK.
> > 
> > Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++++++++++++++++++----
> >  1 file changed, 42 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 6bed75f1541a..3532640c5027 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2520,6 +2520,46 @@ static int intel_planes_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  	return min_cdclk;
> >  }
> >  
> > +static int intel_vdsc_min_cdclk(const struct intel_crtc_state *crtc_state)
> > +{
> > +	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +	struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +	int min_cdclk = 0;
> > +
> > +	/*
> > +	 * When we decide to use only one VDSC engine, since
> > +	 * each VDSC operates with 1 ppc throughput, pixel clock
> > +	 * cannot be higher than the VDSC clock (cdclk)
> > +	 */
> > +	if (!crtc_state->dsc.dsc_split)
> > +		min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +
> > +	if (crtc_state->bigjoiner_pipes) {
> > +		/*
> > +		 * According to Bigjoiner bw check:
> > +		 * compressed_bpp <= PPC * CDCLK * Big joiner Interface bits / Pixel clock
> > +		 *
> > +		 * We have already computed compressed_bpp, so now compute the min CDCLK that
> > +		 * is required to support this compressed_bpp.
> > +		 *
> > +		 * => CDCLK >= compressed_bpp * Pixel clock / (PPC * Bigjoiner Interface bits)
> > +		 *
> > +		 * Since Num of pipes joined = 2, and PPC = 2 with bigjoiner
> > +		 * => CDCLK >= compressed_bpp * pixel_rate  / Bigjoiner Interface bits
> > +		 *
> > +		 * #TODO Bspec mentions to account for FEC overhead while using pixel clock.
> > +		 * Check if we need to use FEC overhead in the above calculations.
> > +		 */
> > +		int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
> > +		int min_cdclk_bj = crtc_state->dsc.compressed_bpp * crtc_state->pixel_rate /
> > +				   bigjoiner_interface_bits;
> 
> pixel_rate is the downscale adjusted thing, so it doesn't seem
> like the correct thing to use here.
> 
> Hmm. Assuming that the single VDSC engine really throttles the entire
> pipe to 1 PPC then we should probably account for the 1 vs. 2 PPC
> difference in *_plane_min_cdclk() and intel_pixel_rate_to_cdclk()
> directly. Currently all of those assume 2 PPC.

Main thing is to properly align that one you propose above with that check,
where we decide how many VDSC engines to use:

        /*
         * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
         * is greater than the maximum Cdclock and if slice count is even
         * then we need to use 2 VDSC instances.
         */
        if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
                if (pipe_config->dsc.slice_count > 1) {
                        pipe_config->dsc.dsc_split = true;
                } else {
                        drm_dbg_kms(&dev_priv->drm,
                                    "Cannot split stream to use 2 VDSC instances\n");
                        return -EINVAL;
                }
        }

Otherwise I agree that we should do that check preferrably in *_plane_min_cdclk
and use plane data rate which is adjusted after scaling is applied(I think we even have correspondent function there)
It is strange that scaling wasn't mentioned in BSpec formula.
I would also say that we should account for number of slices(i.e VDSC engines) now only in Bigjoiner case, but always, as I understand that number can be different not only for Bigjoiner cases.

Stan


> 
> > +
> > +		min_cdclk = max(min_cdclk, min_cdclk_bj);
> > +	}
> > +
> > +	return min_cdclk;
> > +}
> > +
> >  int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  {
> >  	struct drm_i915_private *dev_priv =
> > @@ -2591,13 +2631,8 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  	/* Account for additional needs from the planes */
> >  	min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> >  
> > -	/*
> > -	 * When we decide to use only one VDSC engine, since
> > -	 * each VDSC operates with 1 ppc throughput, pixel clock
> > -	 * cannot be higher than the VDSC clock (cdclk)
> > -	 */
> > -	if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
> > -		min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +	if (crtc_state->dsc.compression_enable)
> > +		min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
> >  
> >  	/*
> >  	 * HACK. Currently for TGL/DG2 platforms we calculate
> > -- 
> > 2.25.1
> 
> -- 
> Ville Syrjälä
> Intel

  reply	other threads:[~2023-05-16 10:12 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12  6:24 [Intel-gfx] [PATCH 00/13] DSC misc fixes Ankit Nautiyal
2023-05-12  6:24 ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 01/13] drm/i915/dp: Consider output_format while computing dsc bpp Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-15 13:20   ` [Intel-gfx] " Ville Syrjälä
2023-05-15 13:20     ` Ville Syrjälä
2023-05-12  6:24 ` [Intel-gfx] [PATCH 02/13] drm/i915/dp_mst: Use output_format to get the final link bpp Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 03/13] drm/i915/dp: Use consistent name for link bpp and compressed bpp Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 04/13] drm/i915/dp: Update Bigjoiner interface bits for computing " Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-15 13:51   ` [Intel-gfx] " Ville Syrjälä
2023-05-15 13:51     ` Ville Syrjälä
2023-05-18 13:16     ` [Intel-gfx] " Nautiyal, Ankit K
2023-05-18 13:16       ` Nautiyal, Ankit K
2023-05-12  6:24 ` [Intel-gfx] [PATCH 05/13] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-15 14:44   ` [Intel-gfx] " Ville Syrjälä
2023-05-15 14:44     ` Ville Syrjälä
2023-05-16 10:11     ` Lisovskiy, Stanislav [this message]
2023-05-16 10:11       ` Lisovskiy, Stanislav
2023-05-18 13:14       ` [Intel-gfx] " Nautiyal, Ankit K
2023-05-18 13:14         ` Nautiyal, Ankit K
2023-05-12  6:24 ` [Intel-gfx] [PATCH 06/13] drm/i915/dp: Remove extra logs for printing DSC info Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 07/13] drm/display/dp: Fix the DP DSC Receiver cap size Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 08/13] drm/i915/dp: Avoid forcing DSC BPC for MST case Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 09/13] drm/i915/dp: Check min bpc DSC limits for dsc_force_bpc also Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 10/13] drm/i915/dp: Avoid left shift of DSC output bpp by 4 Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 11/13] drm/i915/dp: Rename helpers to get DSC max pipe_bpp/output_bpp Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  6:24 ` [Intel-gfx] [PATCH 12/13] drm/i915/dp: Get optimal link config to have best compressed bpp Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-16 10:43   ` [Intel-gfx] " Lisovskiy, Stanislav
2023-05-16 10:43     ` Lisovskiy, Stanislav
2023-05-16 11:40     ` [Intel-gfx] " Ville Syrjälä
2023-05-16 11:40       ` Ville Syrjälä
2023-05-18 13:25       ` [Intel-gfx] " Nautiyal, Ankit K
2023-05-18 13:25         ` Nautiyal, Ankit K
2023-05-23  9:01       ` [Intel-gfx] " Lisovskiy, Stanislav
2023-05-23  9:01         ` Lisovskiy, Stanislav
2023-05-24 12:38         ` [Intel-gfx] " Ville Syrjälä
2023-05-24 12:38           ` Ville Syrjälä
2023-05-24 12:59           ` [Intel-gfx] " Lisovskiy, Stanislav
2023-05-24 12:59             ` Lisovskiy, Stanislav
2023-05-24 13:16             ` [Intel-gfx] " Ville Syrjälä
2023-05-24 13:16               ` Ville Syrjälä
2023-05-12  6:24 ` [Intel-gfx] [PATCH 13/13] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info Ankit Nautiyal
2023-05-12  6:24   ` Ankit Nautiyal
2023-05-12  7:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DSC misc fixes Patchwork
2023-05-12  7:10 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-05-12  7:26 ` [Intel-gfx] ✗ Fi.CI.BAT: 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=ZGNWnP1/vWckkAkA@intel.com \
    --to=stanislav.lisovskiy@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.