All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kulkarni, Vandita" <vandita.kulkarni@intel.com>
To: "Navare, Manasi D" <manasi.d.navare@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Nikula, Jani" <jani.nikula@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
Date: Thu, 28 Oct 2021 04:37:10 +0000	[thread overview]
Message-ID: <7d0b19226c71402199351b7e8514c041@intel.com> (raw)
In-Reply-To: <20211027192642.GA22973@labuser-Z97X-UD5H>

> -----Original Message-----
> From: Navare, Manasi D <manasi.d.navare@intel.com>
> Sent: Thursday, October 28, 2021 12:57 AM
> To: Kulkarni, Vandita <vandita.kulkarni@intel.com>
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani <jani.nikula@intel.com>
> Subject: Re: [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp
> 
> On Wed, Oct 27, 2021 at 03:23:16PM +0530, Vandita Kulkarni wrote:
> > DP 1.4 spec limits max compression bpp to uncompressed bpp -1, which
> > is supported from XELPD onwards.
> > Instead of uncompressed bpp, max dsc input bpp was being used to limit
> > the max compression bpp.
> 
> So the input Pipe BPP which is the uncompressed bpp is decided by the input
> bpc and when this was initially written, we had designed it to respect the
> max_req_bpc by the user.
> So that is what we use to decide the input bpc and hence the pipe_bpp This
> input pipe_bpp decides the compressed bpp that we calculate based on all
> the supported output bpps which are supported all the way upto
> uncompressed_output_bpp - 1.
> 
> So I dont see the need to change the logic here. Moreover I dont see any
> change in the dsc_compute_bpp function So I dont understand the purpose
> of introducing the new max_dsc_pipe_bpp variable here

Thanks for the comments, I had few more opens around this along with this patch.

AFAIU about max_requested_bpc it is to limit the max_bpc
"drm: Add connector property to limit max bpc"
And the driver is supposed to program the default bpc as per the connector limitation.
Which is 12 as per the current driver implementation.

I had few queries around this design:
So it means that max_dsc_input_bpp would be set to 36 if supported by the sink and the platform.
And now we make this as our pipe_bpp,
1. Does this mean that we are assuming 12bpc as i/p always?
2. What happens to those with formats 8bpc, 10 bpc?

We do not consider the actual pipe_bpp while computing the compression_bpp, 
We reverse calculate it from the link_rate,  and small joiner bpp limits.
In cases of forcing dsc, we might have a situation where the link can actually support the current bpp, or even more.
But we are forcing the dsc enable.
In such cases we might end up with a compression bpp which is higher than the actual i/p bpp.

Now, even if we take a min of  higher compression bpp against max_requested_bpc *3 -1, we still have
Compression bpp > actual pipe_bpp 

As per the spec when they say uncompressed bpp, they actually mean 3 * bpc
If we go ahead with this approach of using max_requested_bpc , which is 12 always we cannot
adhere to the spec.

Thanks,
Vandita

> Manasi
> 
> >
> > Fixes: 831d5aa96c97 ("drm/i915/xelpd: Support DP1.4 compression BPPs")
> > Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 9d8132dd4cc5..1f7e666ae490 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1322,7 +1322,7 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >  	struct drm_i915_private *dev_priv = to_i915(dig_port-
> >base.base.dev);
> >  	const struct drm_display_mode *adjusted_mode =
> >  		&pipe_config->hw.adjusted_mode;
> > -	int pipe_bpp;
> > +	int pipe_bpp, max_dsc_pipe_bpp;
> >  	int ret;
> >
> >  	pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) && @@ -
> 1331,7
> > +1331,8 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> >  	if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> >  		return -EINVAL;
> >
> > -	pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state-
> >max_requested_bpc);
> > +	pipe_bpp = pipe_config->pipe_bpp;
> > +	max_dsc_pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> > +conn_state->max_requested_bpc);
> >
> >  	/* Min Input BPC for ICL+ is 8 */
> >  	if (pipe_bpp < 8 * 3) {
> > @@ -1345,7 +1346,7 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> >  	 * Optimize this later for the minimum possible link rate/lane count
> >  	 * with DSC enabled for the requested mode.
> >  	 */
> > -	pipe_config->pipe_bpp = pipe_bpp;
> > +	pipe_config->pipe_bpp = max_dsc_pipe_bpp;
> >  	pipe_config->port_clock = limits->max_rate;
> >  	pipe_config->lane_count = limits->max_lane_count;
> >
> > --
> > 2.32.0
> >

  reply	other threads:[~2021-10-28  4:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  9:53 [Intel-gfx] [PATCH] drm/i915/dsc: Fix the usage of uncompressed bpp Vandita Kulkarni
2021-10-27 14:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-10-27 18:02 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-10-27 19:26 ` [Intel-gfx] [PATCH] " Navare, Manasi
2021-10-28  4:37   ` Kulkarni, Vandita [this message]
2021-10-29 23:12     ` Navare, Manasi
2021-11-01 16:45       ` Kulkarni, Vandita
2021-11-02  4:40         ` Navare, Manasi
2021-11-02  4:35           ` Kulkarni, Vandita
2021-11-02 15:09             ` Navare, Manasi

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=7d0b19226c71402199351b7e8514c041@intel.com \
    --to=vandita.kulkarni@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=manasi.d.navare@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.