Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Shankar, Uma" <uma.shankar@intel.com>
To: Andres Calderon Jaramillo <andrescj@google.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: Andres Calderon Jaramillo <andrescj@chromium.org>,
	"seanpaul@chromium.org" <seanpaul@chromium.org>,
	"Venkatesh Reddy, Sushma" <sushma.venkatesh.reddy@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes
Date: Mon, 14 Dec 2020 22:57:03 +0000	[thread overview]
Message-ID: <9448bc8ea67a49d6a1ebf208824e5472@intel.com> (raw)
In-Reply-To: <20201214221934.2478240-1-andrescj@google.com>



> -----Original Message-----
> From: andrescj via sendgmr <andrescj@andrescj-cros-specialist.c.googlers.com>
> On Behalf Of Andres Calderon Jaramillo
> Sent: Tuesday, December 15, 2020 3:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma <uma.shankar@intel.com>; Venkatesh Reddy, Sushma
> <sushma.venkatesh.reddy@intel.com>; seanpaul@chromium.org; Andres
> Calderon Jaramillo <andrescj@chromium.org>
> Subject: [PATCH] drm/i915/display: Prevent double YUV range correction on HDR
> planes
> 
> From: Andres Calderon Jaramillo <andrescj@chromium.org>
> 
> Prevent the ICL HDR plane pipeline from performing YUV color range correction
> twice when the input is in limited range.
> 
> Before this patch the following could happen: user space gives us a YUV buffer in
> limited range; per the pipeline in [1], the plane would first go through a "YUV
> Range correct" stage that expands the range; the plane would then go through
> the "Input CSC" stage which would also expand the range because
> icl_program_input_csc() would use a matrix and an offset that assume limited-
> range input; this would ultimately cause dark and light colors to appear darker
> and lighter than they should respectively.
> 
> This is an issue because if a buffer switches between being scanned out and
> being composited with the GPU, the user will see a color difference.
> If this switching happens quickly and frequently, the user will perceive this as a
> flickering.
> 
> [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-
> vol12-displayengine_0.pdf#page=281

Change looks good to me, double conversion should not be done.
Plane input csc coefficients take care of the limited range.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>

> Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 761be8deaa9b..aeea344b06ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4811,6 +4811,13 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
>  			plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
>  	} else if (fb->format->is_yuv) {
>  		plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> +
> +		/*
> +		 * Disable the YUV range correction stage because the input CSC
> +		 * stage already takes care of range conversion by using separate
> +		 * matrices and offsets depending on the color range.
> +		 */
> +		plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
>  	}
> 
>  	return plane_color_ctl;
> --
> 2.29.2.684.gfbc64c5ab5-goog

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-12-14 22:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 22:19 [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes Andres Calderon Jaramillo
2020-12-14 22:57 ` Shankar, Uma [this message]
2020-12-15 18:01   ` Ville Syrjälä
2020-12-15 20:06     ` Andres Calderon Jaramillo
2020-12-15 20:13       ` Ville Syrjälä
2020-12-15 22:42         ` [Intel-gfx] [PATCH v2] " Andres Calderon Jaramillo
2021-01-27 23:39           ` Ville Syrjälä
2020-12-16  6:46         ` [Intel-gfx] [PATCH] " Andres Calderon Jaramillo
2020-12-16 11:18           ` Ville Syrjälä
2020-12-15 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2020-12-15 21:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-12-16  0:51 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) Patchwork
2020-12-16  1:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-12-16  7:54 ` [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=9448bc8ea67a49d6a1ebf208824e5472@intel.com \
    --to=uma.shankar@intel.com \
    --cc=andrescj@chromium.org \
    --cc=andrescj@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=seanpaul@chromium.org \
    --cc=sushma.venkatesh.reddy@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