Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk
Date: Tue, 25 Jul 2023 13:10:22 +0300	[thread overview]
Message-ID: <ZL+fcPALvPpotftH@intel.com> (raw)
In-Reply-To: <b0af2b8b-9ad7-d598-b7d4-c9aa6dde56c5@intel.com>

On Tue, Jul 25, 2023 at 11:22:52AM +0530, Nautiyal, Ankit K wrote:
> 
> On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote:
> > On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote:
> > > Currently we assume 2 Pixels Per Clock (PPC) while computing
> > > plane cdclk and min_cdlck. In cases where DSC single engine
> > > is used the throughput is 1 PPC.
> > > 
> > > So account for the above case, while computing cdclk.
> > > 
> > > v2: Use helper to get the adjusted pixel rate.
> > > 
> > > Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> > > ---
> > >   drivers/gpu/drm/i915/display/intel_cdclk.c         |  2 +-
> > >   drivers/gpu/drm/i915/display/intel_vdsc.c          | 12 ++++++++++++
> > >   drivers/gpu/drm/i915/display/intel_vdsc.h          |  2 ++
> > >   drivers/gpu/drm/i915/display/skl_universal_plane.c |  4 ++--
> > >   4 files changed, 17 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index dcc1f6941b60..701909966545 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2508,7 +2508,7 @@ static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state *crtc_state)
> > >   	int pixel_rate = crtc_state->pixel_rate;
> > >   	if (DISPLAY_VER(dev_priv) >= 10)
> > > -		return DIV_ROUND_UP(pixel_rate, 2);
> > > +		return intel_dsc_get_adjusted_pixel_rate(crtc_state, pixel_rate);
> > >   	else if (DISPLAY_VER(dev_priv) == 9 ||
> > >   		 IS_BROADWELL(dev_priv) || IS_HASWELL(dev_priv))
> > >   		return pixel_rate;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > index 9d76c2756784..bbfdbf06da68 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > @@ -1038,3 +1038,15 @@ void intel_dsc_get_config(struct intel_crtc_state *crtc_state)
> > >   out:
> > >   	intel_display_power_put(dev_priv, power_domain, wakeref);
> > >   }
> > > +
> > > +int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state *crtc_state, int pixel_rate)
> > > +{
> > > +	/*
> > > +	 * If single VDSC engine is used, it uses one pixel per clock
> > > +	 * otherwise we use two pixels per clock.
> > > +	 */
> > > +	if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
> > > +		return pixel_rate;
> > > +
> > > +	return DIV_ROUND_UP(pixel_rate, 2);
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.h b/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > index 2cc41ff08909..3bb4b1980b6b 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.h
> > > @@ -28,4 +28,6 @@ void intel_dsc_dsi_pps_write(struct intel_encoder *encoder,
> > >   void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
> > >   			    const struct intel_crtc_state *crtc_state);
> > > +int intel_dsc_get_adjusted_pixel_rate(const struct intel_crtc_state *crtc_state, int pixel_rate);
> > > +
> > >   #endif /* __INTEL_VDSC_H__ */
> > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > index 6b01a0b68b97..9eeb25ec4be9 100644
> > > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > > @@ -17,6 +17,7 @@
> > >   #include "intel_fb.h"
> > >   #include "intel_fbc.h"
> > >   #include "intel_psr.h"
> > > +#include "intel_vdsc.h"
> > >   #include "skl_scaler.h"
> > >   #include "skl_universal_plane.h"
> > >   #include "skl_watermark.h"
> > > @@ -263,8 +264,7 @@ static int icl_plane_min_cdclk(const struct intel_crtc_state *crtc_state,
> > >   {
> > >   	unsigned int pixel_rate = intel_plane_pixel_rate(crtc_state, plane_state);
> > > -	/* two pixels per clock */
> > > -	return DIV_ROUND_UP(pixel_rate, 2);
> > > +	return intel_dsc_get_adjusted_pixel_rate(crtc_state, pixel_rate);
> > Hi Ankit,
> > 
> > I think the thing what you are taking of is already handled here in intel_cdclk.c:
> > 
> > 	/*
> >           * 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 there 2 VDSC engines, then pixel clock can't be higher than
> >           * VDSC clock(cdclk) * 2 and so on.
> >           */
> >          if (crtc_state->dsc.compression_enable) {
> >                  int num_vdsc_instances = intel_dsc_get_num_vdsc_instances(crtc_state);
> > 
> >                  min_cdclk = max_t(int, min_cdclk,
> >                                    DIV_ROUND_UP(crtc_state->pixel_rate,
> >                                                 num_vdsc_instances));
> >          }
> 
> As far as I understand this condition is coming from the pixel clock
> limitation as an input to the splitter (Bspec: 49259):
> 
> Pipe BW check:
> 
> Pixel clock < PPC * CDCLK frequency * Number of pipes joined
> 
> PPC = 1 or 2 depending on number of DSC engines used within the pipe.
> 
> So it implies CDCLK frequency > Pixel clock / (PPC * Number of pipes joined)
> 
> num_vdsc_instances is actually giving us (PPC * number of pipes joined).
> 
> 
> I completely agree that there will be no effect of the change on the
> min_cdclk that gets computed in any case, whether DSC, 1 engine, 2 engine, 
> bigjoiner or no DSC.
> 
> Only thing is for the case where 1 DSC engine is used, what
> intel_pixel_rate_to_cdclk return will be different, and its due to the fact
> that pipe is driven with 1PPC.
> 
> But as I said, the min_cdclk computed will be same as without patch. So we
> can certainly do away with this change, and I can drop this from the patch.
> 
> 
> But in case of icl_plane_min_cdclk, currently we are dividing the
> plane_pixel_rate by 2, citing that we use 2 pixel per clock, to get the
> plane_min_cdclk.
> 
> Should this not be 1 PPC in case where single DSC engine is used? In that
> case plane_min_cdclk will be double. Should we keep the change only for
> plane_min_cdclk then?

Those are different cases:


1) When we are not using DSC, we are always processing
2 pixels per CDCLK, starting from gen 10. It is reflected in both intel_pixel_rate_to_cdclk
and icl_plane_min_cdclk(which is a bit of a tautology I agree, but anyways we always take 
all limitations and use max(worst case) of them)

2) When we are using DSC. In that case we could use 1 or VDSC engines, which would set PPC to
1 or 2 correspondently. So whenever we happen to use DSC that condition will take max of
the CDCLK obtained by other requirements and that formula.
However in non-compressed case when there is no DSC, we should even be insterested in querying
how many VDSC instances we have, amount of pixels processed per CDCLK isn't related to this in
that case.

Stan

> 
> 
> Regards,
> 
> Ankit
> 
> 
> > 
> > Also even if something still have to be done here, I think we should preferrably
> > deal with anything related to DSC in a single place, to prevent any kind of
> > confusion(when those checks are scattered in different places, it is way more easy to forget/not notice something)
> > 
> > I think intel_pixel_rate_to_cdclk isn't supposed to know anything about DSC or any other specifics like audio checks and etc - it is
> > just dealing with the "default" uncompressed case.
> > Any other additional limitations or checks we apply after those, as there are
> > quite many anyway.
> > 
> > Stan
> > 
> > 
> > >   }
> > >   static void
> > > -- 
> > > 2.40.1
> > > 

  reply	other threads:[~2023-07-25 10:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 10:33 [Intel-gfx] [PATCH 00/19] DSC misc fixes Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 01/19] drm/i915/dp: Consider output_format while computing dsc bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 02/19] drm/i915/dp: Move compressed bpp check with 420 format inside the helper Ankit Nautiyal
2023-07-14  3:23   ` Murthy, Arun R
2023-07-13 10:33 ` [Intel-gfx] [PATCH 03/19] drm/i915/dp_mst: Use output_format to get the final link bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 04/19] drm/i915/dp: Use consistent name for link bpp and compressed bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing " Ankit Nautiyal
2023-07-20  9:29   ` Lisovskiy, Stanislav
2023-07-24 12:19     ` Nautiyal, Ankit K
2023-07-25 10:13       ` Lisovskiy, Stanislav
2023-07-25 11:19         ` Nautiyal, Ankit K
2023-07-28  4:18           ` Nautiyal, Ankit K
2023-07-13 10:33 ` [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk Ankit Nautiyal
2023-07-20  9:16   ` Lisovskiy, Stanislav
2023-07-25  5:52     ` Nautiyal, Ankit K
2023-07-25 10:10       ` Lisovskiy, Stanislav [this message]
2023-07-25 11:22         ` Nautiyal, Ankit K
2023-07-13 10:33 ` [Intel-gfx] [PATCH 07/19] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck Ankit Nautiyal
2023-07-20  9:24   ` Lisovskiy, Stanislav
2023-07-25  6:01     ` Nautiyal, Ankit K
2023-07-13 10:33 ` [Intel-gfx] [PATCH 08/19] drm/i915/dp: Remove extra logs for printing DSC info Ankit Nautiyal
2023-07-14  3:28   ` Murthy, Arun R
2023-07-13 10:33 ` [Intel-gfx] [PATCH 09/19] drm/display/dp: Fix the DP DSC Receiver cap size Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 10/19] drm/i915/dp: Avoid forcing DSC BPC for MST case Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 11/19] drm/i915/dp: Add functions to get min/max src input bpc with DSC Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 12/19] drm/i915/dp: Check min bpc DSC limits for dsc_force_bpc also Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 13/19] drm/i915/dp: Avoid left shift of DSC output bpp by 4 Ankit Nautiyal
2023-07-20  9:31   ` Lisovskiy, Stanislav
2023-07-13 10:33 ` [Intel-gfx] [PATCH 14/19] drm/i915/dp: Rename helper to get DSC max pipe_bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 15/19] drm/i915/dp: Separate out functions for edp/DP for computing DSC bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 16/19] drm/i915/dp: Add DSC BPC/BPP constraints while selecting pipe bpp with DSC Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 17/19] drm/i915/dp: Separate out function to get compressed bpp with joiner Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 18/19] drm/i915/dp: Get optimal link config to have best compressed bpp Ankit Nautiyal
2023-07-13 10:33 ` [Intel-gfx] [PATCH 19/19] drm/i915: Query compressed bpp properly using correct DPCD and DP Spec info Ankit Nautiyal
2023-07-13 11:56 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for DSC misc fixes (rev4) Patchwork
2023-07-13 12:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-13 15:14 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2023-06-30 12:46 [Intel-gfx] [PATCH 00/19] DSC misc fixes Ankit Nautiyal
2023-06-30 12:46 ` [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk Ankit Nautiyal

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=ZL+fcPALvPpotftH@intel.com \
    --to=stanislav.lisovskiy@intel.com \
    --cc=ankit.k.nautiyal@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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