From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v11 06/11] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid
Date: Mon, 20 Mar 2023 10:26:58 +0200 [thread overview]
Message-ID: <ZBgY0qtd2liVZt8q@intel.com> (raw)
In-Reply-To: <3abeb6b7-18b4-26cd-be4e-2644bfe18dc9@intel.com>
On Mon, Mar 20, 2023 at 09:06:25AM +0530, Nautiyal, Ankit K wrote:
>
> On 3/17/2023 6:30 AM, Ville Syrjälä wrote:
> > On Tue, Mar 14, 2023 at 04:34:10PM +0530, Ankit Nautiyal wrote:
> >> During modevalid step, the pipe bpp is computed assuming RGB output
> >> format. When checking with DSC, consider the output_format and compute
> >> the input bpp for DSC appropriately.
> >>
> >> v2: For DP-MST we currently use RGB output format only, so continue
> >> using RGB while computing dsc_bpp for MST case.
> >>
> >> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 28 ++++++++++++++++-----
> >> drivers/gpu/drm/i915/display/intel_dp.h | 4 ++-
> >> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> >> 3 files changed, 26 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index dcb3c2519041..499390c519ca 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -1110,11 +1110,21 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> >>
> >> if (HAS_DSC(dev_priv) &&
> >> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> >> + int pipe_bpp;
> >> + enum intel_output_format output_format, sink_format;
> >> + const struct drm_display_info *info = &connector->base.display_info;
> >> +
> >> + if ( (info, mode))
> >> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> >> + else
> >> + sink_format = INTEL_OUTPUT_FORMAT_RGB;
> > I think I saw this same code duplicated somewhere else already.
> > Time for a intel_dp_sink_format()?
>
> Yes this can be made as a common function, also used in
> intel_dp_mode_min_output_bpp.
>
> Will add the helper intel_dp_sink_format for this.
>
> >
> >> +
> >> + output_format = intel_dp_output_format(connector, sink_format);
> >> /*
> >> * TBD pass the connector BPC,
> >> * for now U8_MAX so that max BPC on that platform would be picked
> >> */
> >> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> >> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, output_format, U8_MAX);
> >>
> >> /*
> >> * Output bpp is stored in 6.4 format so right shift by 4 to get the
> >> @@ -1454,12 +1464,15 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
> >> return -EINVAL;
> >> }
> >>
> >> -int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> >> +int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp,
> >> + enum intel_output_format output_format,
> >> + u8 max_req_bpc)
> >> {
> >> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >> int i, num_bpc;
> >> u8 dsc_bpc[3] = {0};
> >> u8 dsc_max_bpc;
> >> + int pipe_bpp = 0;
> >>
> >> /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> >> if (DISPLAY_VER(i915) >= 12)
> >> @@ -1470,11 +1483,13 @@ int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> >> num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd,
> >> dsc_bpc);
> >> for (i = 0; i < num_bpc; i++) {
> >> - if (dsc_max_bpc >= dsc_bpc[i])
> >> - return dsc_bpc[i] * 3;
> >> + if (dsc_max_bpc >= dsc_bpc[i]) {
> >> + pipe_bpp = dsc_bpc[i] * 3;
> >> + break;
> >> + }
> >> }
> >>
> >> - return 0;
> >> + return intel_dp_output_bpp(output_format, pipe_bpp);
> > The pipe_bpp vs. output_bpp terms seem a bit confused now in the dsc
> > code.
> >
> > In the non-compressed cases pipe_bpp does not include any
> > subsampling, output_bpp is the subsampled version.
> >
> > What this dsc code seems to want is an intermediate value which
> > is the subsampled pipe_bpp that is the input to dsc compressor?
> > And output_bpp/dsc.compressed_bpp is then the final bpp coming
> > out of the compressor.
>
>
> Yes I now realize, this is wrong, it should have been pipe_bpp not the
> subsampled pipe_bpp.
>
> As I understand, we are using subsampled pipe_bpp only to compute the
> bandwidth/clock checks.
>
> You are right, we need use pipe_bpp for programming, and the same is
> input to DSC, and not the subsampled pipe_bpp.
>
> I Will remove this line from the function.
>
> >
> > I think we should invent a consistent set of names for each so that
> > it's clear which value the code is concerned with.
>
> Yes you are right output_bpp is used as compressed_bpp in some places,
> functions.
>
> We can go with something like this perhaps:
>
> pipe_bpp : the actual bits_per_pixel, that we program
>
> output_bpp : In case of YcbCr420,422 output format bytes_per_pixel will
> be half the number of bytes of RGB pixel.
>
> compressed_bpp : (Only for DSC case) the target BPP for the DSC encoder,
> after compression.
>
> Does this make sense? I can try to have a separate patch for this.
Then I think we need a new name for the final bpp in
intel_dp_compute_config() at least. Hmm, maybe link_bpp?
intel_dp_compute_link_config_wide() should perhaps use that
same name as well.
>
>
> >> }
> >>
> >> static int intel_dp_source_dsc_version_minor(struct intel_dp *intel_dp)
> >> @@ -1588,7 +1603,8 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> >> return -EINVAL;
> >>
> >> if (compute_pipe_bpp)
> >> - pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state->max_requested_bpc);
> >> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, pipe_config->output_format,
> >> + conn_state->max_requested_bpc);
> > This pipe_bpp gets plugged back into crtc_state->pipe_bpp later and
> > then it'll be the subsampled version. I don't think that is what we want
> > eg. for dithering setup and whatnot.
>
> You are right, this is incorrect. Removing the line as mentioned above
> will fix this.
>
> Thanks for pointing out this issue. I will fix this in next version of
> the patch.
>
>
> Regards,
>
> Ankit
>
> >
> >> else
> >> pipe_bpp = pipe_config->pipe_bpp;
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
> >> index ef39e4f7a329..2f4136e43f38 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> >> @@ -102,7 +102,9 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
> >> struct intel_crtc_state *crtc_state,
> >> unsigned int type);
> >> bool intel_digital_port_connected(struct intel_encoder *encoder);
> >> -int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc);
> >> +int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp,
> >> + enum intel_output_format output_format,
> >> + u8 dsc_max_bpc);
> >> u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> >> u32 link_clock, u32 lane_count,
> >> u32 mode_clock, u32 mode_hdisplay,
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> index ff0b821a901a..bdc5c53ccd75 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> >> @@ -917,7 +917,7 @@ intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
> >> * TBD pass the connector BPC,
> >> * for now U8_MAX so that max BPC on that platform would be picked
> >> */
> >> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> >> + int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, INTEL_OUTPUT_FORMAT_RGB, U8_MAX);
> >>
> >> if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
> >> dsc_max_output_bpp =
> >> --
> >> 2.25.1
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-03-20 8:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 11:04 [Intel-gfx] [PATCH v11 00/11] Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 01/11] drm/i915/display: Add new member to configure PCON color conversion Ankit Nautiyal
2023-03-17 0:24 ` Ville Syrjälä
2023-03-17 10:07 ` Nautiyal, Ankit K
2023-03-17 11:39 ` Ville Syrjälä
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 02/11] drm/i915/display: Add new member in intel_dp to store ycbcr420 passthrough cap Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 03/11] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format Ankit Nautiyal
2023-03-16 23:46 ` Ville Syrjälä
2023-03-17 10:48 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 04/11] drm/i915/display: Use sink_format instead of ycbcr420_output flag Ankit Nautiyal
2023-03-17 0:25 ` Ville Syrjälä
2023-03-17 11:10 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 05/11] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid Ankit Nautiyal
2023-03-17 0:28 ` Ville Syrjälä
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 06/11] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid Ankit Nautiyal
2023-03-17 1:00 ` Ville Syrjälä
2023-03-20 3:36 ` Nautiyal, Ankit K
2023-03-20 8:26 ` Ville Syrjälä [this message]
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 07/11] drm/i915/display: Add helper function to check if sink_format is 420 Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 08/11] drm/i915/dp: Avoid DSC with output_format YCBCR420 Ankit Nautiyal
2023-03-14 17:33 ` Manasi Navare
2023-03-16 11:20 ` Nautiyal, Ankit K
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 09/11] drm/i915/dp: Handle BPP where HDMI2.1 DFP doesn't support DSC Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 10/11] drm/i915/dp: Fix FRL BW check for HDMI2.1 DFP Ankit Nautiyal
2023-03-14 11:04 ` [Intel-gfx] [PATCH v11 11/11] drm/i915/dp: Add a wrapper to check frl/tmds downstream constraints Ankit Nautiyal
2023-03-14 15:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes (rev12) Patchwork
2023-03-15 19:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=ZBgY0qtd2liVZt8q@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ankit.k.nautiyal@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 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.