From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output
Date: Thu, 9 Mar 2023 14:01:06 +0530 [thread overview]
Message-ID: <885ac9ea-97cf-b35d-c75a-6f1d28c27386@intel.com> (raw)
In-Reply-To: <ZAipD8UzhW3dOUGW@intel.com>
Hi Ville,
Thanks for the comments and suggestions. Please find my response inline:
On 3/8/2023 8:56 PM, Ville Syrjälä wrote:
> On Wed, Mar 08, 2023 at 05:10:57PM +0200, Ville Syrjälä wrote:
>> On Mon, Feb 27, 2023 at 09:33:14AM +0530, Ankit Nautiyal wrote:
>>> For YCbCr420 output, scaler is required for downsampling.
>>> Scaler can be used only when source size smaller than max_src_w and
>>> max_src_h as defined by for the platform.
>>> So go for native YCbCr420 only if there are no scaler constraints.
>>>
>>> v2: Corrected max-width based on Display Version.
>>>
>>> v3: Updated max-width as per latest Bspec change.
>>>
>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dp.c | 41 ++++++++++++++++++++++---
>>> 1 file changed, 37 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>>> index 1a30cc021b25..e95fc0f0d13a 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -804,11 +804,36 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
>>> return 0;
>>> }
>>>
>>> +static bool
>>> +ycbcr420_scaler_constraints(struct drm_i915_private *i915,
>>> + const struct drm_display_mode *mode)
>>> +{
>>> + int max_src_w, max_src_h;
>>> +
>>> + if (DISPLAY_VER(i915) < 11) {
>>> + max_src_w = 4096;
>>> + max_src_h = 4096;
>>> + } else if (DISPLAY_VER(i915) < 12) {
>>> + max_src_w = 5120;
>>> + max_src_h = 4096;
>>> + } else if (DISPLAY_VER(i915) < 14) {
>>> + max_src_w = 5120;
>>> + max_src_h = 8192;
>>> + } else {
>>> + max_src_w = 4096;
>>> + max_src_h = 8192;
>>> + }
>>> +
>>> + return mode->hdisplay > max_src_w || mode->vdisplay > max_src_h;
>>> +}
>>> +
>> I don't really like this. If we do something like this
>> then it should be the scaler code that checks this stuff.
Makes sense, this does belong to the scaler file and scaler checks.
>>
>> However, after pondering about this more I'm actually
>> leaning towards using 4:4:4 output whenever possible,
>> only going for 4:2:0 if absolutely necessary. That
>> avoids having to deal with all the annoying scaler/etc
>> limitations.
> In fact perhaps best to try RGB first (also avoids the whole
> pipe CSC mess on glk), then YCbCr 4:4:4 (still avoids the
> scaler mess), and finally accepting that we need to do
> native YCbCr 4:2:0 output.
Ok so if I understand correctly, in intel_dp_output_format()
If sink_format is YCBCR420:
-first try with output_format as RGB and RGB->YCBCR420 conv via DFP (if
conv supported)
-Or else try with output_format as YCBCR444 and use YCBCR444->YCBCR420
conv via DFP (if conv supported)
-else try with output_format YCBCR420.
If there are indeed scaler constraints, those are to be taken care in
scaler check code.
Shall I drop the scaler constraint for now and have that as a separate
series?
Regards,
Ankit
>
>>> static enum intel_output_format
>>> intel_dp_output_format(struct intel_connector *connector,
>>> + const struct drm_display_mode *mode,
>>> enum intel_output_format sink_format)
>>> {
>>> struct intel_dp *intel_dp = intel_attached_dp(connector);
>>> + struct drm_i915_private *i915 = to_i915(connector->base.dev);
>>>
>>> if (!connector->base.ycbcr_420_allowed ||
>>> sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
>>> @@ -820,8 +845,15 @@ intel_dp_output_format(struct intel_connector *connector,
>>>
>>> if (intel_dp->dfp.ycbcr_444_to_420)
>>> return INTEL_OUTPUT_FORMAT_YCBCR444;
>>> - else
>>> +
>>> + /*
>>> + * For YCbCr420 output, scaler is required for downsampling
>>> + * So go for native YCbCr420 only if there are no scaler constraints.
>>> + */
>>> + if (!ycbcr420_scaler_constraints(i915, mode))
>>> return INTEL_OUTPUT_FORMAT_YCBCR420;
>>> +
>>> + return INTEL_OUTPUT_FORMAT_RGB;
>>> }
>>>
>>> int intel_dp_min_bpp(enum intel_output_format output_format)
>>> @@ -857,7 +889,7 @@ intel_dp_mode_min_output_bpp(struct intel_connector *connector,
>>> else
>>> sink_format = INTEL_OUTPUT_FORMAT_RGB;
>>>
>>> - output_format = intel_dp_output_format(connector, sink_format);
>>> + output_format = intel_dp_output_format(connector, mode, sink_format);
>>>
>>> return intel_dp_output_bpp(output_format, intel_dp_min_bpp(output_format));
>>> }
>>> @@ -2052,7 +2084,8 @@ intel_dp_compute_output_format(struct intel_encoder *encoder,
>>> crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
>>> }
>>>
>>> - crtc_state->output_format = intel_dp_output_format(connector, crtc_state->sink_format);
>>> + crtc_state->output_format = intel_dp_output_format(connector, adjusted_mode,
>>> + crtc_state->sink_format);
>>>
>>> ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
>>> respect_downstream_limits);
>>> @@ -2063,7 +2096,7 @@ intel_dp_compute_output_format(struct intel_encoder *encoder,
>>> return ret;
>>>
>>> crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>>> - crtc_state->output_format = intel_dp_output_format(connector,
>>> + crtc_state->output_format = intel_dp_output_format(connector, adjusted_mode,
>>> crtc_state->sink_format);
>>> ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
>>> respect_downstream_limits);
>>> --
>>> 2.25.1
>> --
>> Ville Syrjälä
>> Intel
next prev parent reply other threads:[~2023-03-09 8:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 4:03 [Intel-gfx] [PATCH v10 00/13] Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 01/13] drm/i915/display: Add new member to configure PCON color conversion Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 02/13] drm/i915/display: Add new member in intel_dp to store ycbcr420 passthrough cap Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 03/13] drm/i915/dp: Add Scaler constraint for YCbCr420 output Ankit Nautiyal
2023-03-08 15:10 ` Ville Syrjälä
2023-03-08 15:26 ` Ville Syrjälä
2023-03-09 8:31 ` Nautiyal, Ankit K [this message]
2023-03-09 10:21 ` Ville Syrjälä
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 04/13] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 05/13] drm/i915/dp: Compute output format with/without DSC Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 06/13] drm/i915/display: Use sink_format instead of ycbcr420_output flag Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 07/13] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 08/13] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 09/13] drm/i915/display: Add helper function to check if sink_format is 420 Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 10/13] drm/i915/dp: Avoid DSC with output_format YCBCR420 Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 11/13] drm/i915/dp: Handle BPP where HDMI2.1 DFP doesn't support DSC Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 12/13] drm/i915/dp: Fix FRL BW check for HDMI2.1 DFP Ankit Nautiyal
2023-02-27 4:03 ` [Intel-gfx] [PATCH v10 13/13] drm/i915/dp: Add a wrapper to check frl/tmds downstream constraints Ankit Nautiyal
2023-02-27 5:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes (rev11) Patchwork
2023-02-27 7:04 ` [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=885ac9ea-97cf-b35d-c75a-6f1d28c27386@intel.com \
--to=ankit.k.nautiyal@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox