Re: [PATCH v2 1/2] drm/i915/dp: Prefer DSC over 6 bpc uncompressed output for HDMI sinks
"Nautiyal, Ankit K" <[email protected]>
| Newsgroups | org.freedesktop.lists.intel-gfx,org.freedesktop.lists.intel-xe |
|---|---|
| Message-ID | <[email protected]> |
On 7/18/2026 4:22 PM, Alexander Kaplan wrote:
> For modes which fit through the link uncompressed only with a 6 bpc
> pipe BPP, the link config currently selects 6 bpc with dithering even
> if the sink supports DSC.
>
> For HDMI sinks behind a DP to HDMI protocol converter this is the
> wrong preference: HDMI knows no 6 bpc transport format, so the
> converter has to expand the dithered 6 bpc stream back to 8 bpc for
> the HDMI link anyway, and DSC with an at least 8 bpc input provides
> a better output quality than that.
> Prefer DSC, following the pattern commit ba49a4643cf5 ("drm/i915/dp:
> Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the
> uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC,
> making the uncompressed link config fail for such modes and the mode
> fall back to DSC.
> As there, if the DSC computation fails, the mode falls back to YCbCr
> 4:2:0 where supported, or gets rejected.
>
> Besides the output quality, some converters can't even display a
> 6 bpc stream at high pixel clocks.
> Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device
> families (branch device IDs SYNAq and SYNAa) output corrupted FRL
> timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream,
> resulting in a black screen, while the same mode works with DSC
> (12 bpc input) and 6 bpc works at lower pixel clocks.
> Windows and macOS drive 4k120 on these devices only via DSC.
>
> A lower bpc limit explicitly requested via the max bpc connector
> property is still honored.
> This keeps the current uAPI behavior (exercised by IGT kms_dither)
> and provides an escape hatch for sinks with a broken DSC
> implementation.
> DP and eDP sinks, and HDMI sinks without DSC support, are not
> affected and keep falling back to 6 bpc.
>
> Tested on PTL (xe) with the above PCONs and an LG OLED G4.
>
> Cc: Imre Deak <[email protected]>
> Cc: Chaitanya Kumar Borah <[email protected]>
> Cc: Ankit Nautiyal <[email protected]>
> Cc: Ville Syrjälä <[email protected]>
> Signed-off-by: Alexander Kaplan <[email protected]>
> ---
> v2: Apply the limit only to HDMI sinks behind a DFP
> (intel_dp_has_hdmi_sink()), leaving DP and eDP link config
> policy untouched, and adjust the subject accordingly. (Ankit)
>
> drivers/gpu/drm/i915/display/intel_dp.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index b2464a3dac056..7e860f62d5554 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2671,6 +2671,20 @@ intel_dp_compute_config_limits(struct intel_dp *intel_dp,
> crtc_state)));
> }
>
> + /*
> + * HDMI knows no 6 bpc transport format, and DSC with an at least
> + * 8 bpc input provides a better output quality than a dithered
> + * 6 bpc output. Prefer it for HDMI sinks, by failing the
> + * uncompressed link config for modes which would fit only with a
> + * 6 bpc pipe BPP. Honor a lower limit set via the max bpc
> + * connector property.
> + */
> + if (!dsc && intel_dp_has_hdmi_sink(intel_dp) &&
> + intel_dp_supports_dsc(intel_dp, connector, crtc_state) &&
> + limits->pipe.max_bpp >= 24 &&
> + crtc_state->pipe_bpp >= 24)
> + limits->pipe.min_bpp = max(limits->pipe.min_bpp, 24);
Agree with the change.
For HDMI sinks without DSC we keep allowing the dithered 6 bpc
uncompressed config.
For DSC-capable HDMI sinks we skip the 6 bpc uncompressed case and let a
real 8 bpc input be DSC-compressed instead,
giving true 8 bpc at the sink.
A lower max-bpc connector property request is still honored.
LGTM.
Reviewed-by: Ankit Nautiyal <[email protected]>
> +
> if (limits->pipe.min_bpp <= 0 ||
> limits->pipe.min_bpp > limits->pipe.max_bpp) {
> drm_dbg_kms(display->drm, "[CONNECTOR:%d:%s] Invalid pipe bpp range: %d-%d\n",