* [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes
@ 2020-12-14 22:19 Andres Calderon Jaramillo
2020-12-14 22:57 ` Shankar, Uma
` (5 more replies)
0 siblings, 6 replies; 14+ messages in thread
From: Andres Calderon Jaramillo @ 2020-12-14 22:19 UTC (permalink / raw)
To: intel-gfx; +Cc: Andres Calderon Jaramillo, seanpaul, sushma.venkatesh.reddy
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
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 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 2020-12-15 18:01 ` Ville Syrjälä 2020-12-15 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork ` (4 subsequent siblings) 5 siblings, 1 reply; 14+ messages in thread From: Shankar, Uma @ 2020-12-14 22:57 UTC (permalink / raw) To: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org Cc: Andres Calderon Jaramillo, seanpaul@chromium.org, Venkatesh Reddy, Sushma > -----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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-14 22:57 ` Shankar, Uma @ 2020-12-15 18:01 ` Ville Syrjälä 2020-12-15 20:06 ` Andres Calderon Jaramillo 0 siblings, 1 reply; 14+ messages in thread From: Ville Syrjälä @ 2020-12-15 18:01 UTC (permalink / raw) To: Shankar, Uma Cc: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org, Andres Calderon Jaramillo, seanpaul@chromium.org, Venkatesh Reddy, Sushma On Mon, Dec 14, 2020 at 10:57:03PM +0000, Shankar, Uma wrote: > > > > -----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. Might make sense to actually use the hw range correction instead. Would avoid having to keep around two sets of coefficients. Also the question now becomes: How can our tests be passing if we're doing the range correction twice? > > 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 -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-15 18:01 ` Ville Syrjälä @ 2020-12-15 20:06 ` Andres Calderon Jaramillo 2020-12-15 20:13 ` Ville Syrjälä 0 siblings, 1 reply; 14+ messages in thread From: Andres Calderon Jaramillo @ 2020-12-15 20:06 UTC (permalink / raw) To: Ville Syrjälä Cc: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, Venkatesh Reddy, Sushma On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Mon, Dec 14, 2020 at 10:57:03PM +0000, Shankar, Uma wrote: > > > > > > > -----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. > > Might make sense to actually use the hw range correction instead. > Would avoid having to keep around two sets of coefficients. > > Also the question now becomes: How can our tests be passing if > we're doing the range correction twice? > I also considered just removing the limited-range matrix/offsets from icl_program_input_csc(). However, I figured that since the "Input CSC" stage must happen regardless of range correction, maybe it would be a gain to disable the "YUV Range Correction" stage. However, I'm not familiar with the hardware details, so I don't know for sure. I don't feel strongly either way; let me know what you'd prefer. I'm also curious about the testing. How do the tests work? I assume they are in Intel's CI and not open sourced? Do they use the DRM writeback connector (I didn't think this was implemented for i915 yet)? > > > > 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 > > -- > Ville Syrjälä > Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 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 2020-12-16 6:46 ` [Intel-gfx] [PATCH] " Andres Calderon Jaramillo 0 siblings, 2 replies; 14+ messages in thread From: Ville Syrjälä @ 2020-12-15 20:13 UTC (permalink / raw) To: Andres Calderon Jaramillo Cc: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, Venkatesh Reddy, Sushma On Tue, Dec 15, 2020 at 03:06:30PM -0500, Andres Calderon Jaramillo wrote: > On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Mon, Dec 14, 2020 at 10:57:03PM +0000, Shankar, Uma wrote: > > > > > > > > > > -----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. > > > > Might make sense to actually use the hw range correction instead. > > Would avoid having to keep around two sets of coefficients. > > > > Also the question now becomes: How can our tests be passing if > > we're doing the range correction twice? > > > > I also considered just removing the limited-range matrix/offsets from > icl_program_input_csc(). However, I figured that since the "Input CSC" > stage must happen regardless of range correction, maybe it would be a > gain to disable the "YUV Range Correction" stage. However, I'm not > familiar with the hardware details, so I don't know for sure. I don't > feel strongly either way; let me know what you'd prefer. IIRC we use the fixed function range compression + full range csc approach on chv as well. Wouldn't hurt to do the same thing on icl+ IMO. > > I'm also curious about the testing. How do the tests work? I assume > they are in Intel's CI and not open sourced? Do they use the DRM > writeback connector (I didn't think this was implemented for i915 > yet)? Tests are here: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools In particular kms_plane/pixel-format tests should rather be failing I think. Unless we've relaxed things a bit too much to get the crcs to match when the results are close enough. > > > > > > > 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 > > > > -- > > Ville Syrjälä > > Intel -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] [PATCH v2] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-15 20:13 ` Ville Syrjälä @ 2020-12-15 22:42 ` Andres Calderon Jaramillo 2021-01-27 23:39 ` Ville Syrjälä 2020-12-16 6:46 ` [Intel-gfx] [PATCH] " Andres Calderon Jaramillo 1 sibling, 1 reply; 14+ messages in thread From: Andres Calderon Jaramillo @ 2020-12-15 22:42 UTC (permalink / raw) To: intel-gfx; +Cc: Andres Calderon Jaramillo, seanpaul, sushma.venkatesh.reddy 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. This is done by removing the limited-range code from icl_program_input_csc(). 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 Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org> --- Changelog since v1: - Don't skip the YUV range correction stage. Instead, use that stage and modify icl_program_input_csc() to always assume full-range input. drivers/gpu/drm/i915/display/intel_display.c | 2 + drivers/gpu/drm/i915/display/intel_sprite.c | 65 +++----------------- 2 files changed, 12 insertions(+), 55 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 761be8deaa9b..8fb9b4f8c1df 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -4811,6 +4811,8 @@ 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; + if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) + plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE; } return plane_color_ctl; diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index b7e208816074..121e1b5120fd 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -633,13 +633,19 @@ skl_program_scaler(struct intel_plane *plane, /* Preoffset values for YUV to RGB Conversion */ #define PREOFF_YUV_TO_RGB_HI 0x1800 -#define PREOFF_YUV_TO_RGB_ME 0x1F00 +#define PREOFF_YUV_TO_RGB_ME 0x0000 #define PREOFF_YUV_TO_RGB_LO 0x1800 #define ROFF(x) (((x) & 0xffff) << 16) #define GOFF(x) (((x) & 0xffff) << 0) #define BOFF(x) (((x) & 0xffff) << 16) +/* + * Programs the input color space conversion stage for ICL HDR planes. + * Note that it is assumed that this stage always happens after YUV + * range correction. Thus, the input to this stage is assumed to be + * in full-range YCbCr. + */ static void icl_program_input_csc(struct intel_plane *plane, const struct intel_crtc_state *crtc_state, @@ -687,52 +693,7 @@ icl_program_input_csc(struct intel_plane *plane, 0x0, 0x7800, 0x7F10, }, }; - - /* Matrix for Limited Range to Full Range Conversion */ - static const u16 input_csc_matrix_lr[][9] = { - /* - * BT.601 Limted range YCbCr -> full range RGB - * The matrix required is : - * [1.164384, 0.000, 1.596027, - * 1.164384, -0.39175, -0.812813, - * 1.164384, 2.017232, 0.0000] - */ - [DRM_COLOR_YCBCR_BT601] = { - 0x7CC8, 0x7950, 0x0, - 0x8D00, 0x7950, 0x9C88, - 0x0, 0x7950, 0x6810, - }, - /* - * BT.709 Limited range YCbCr -> full range RGB - * The matrix required is : - * [1.164384, 0.000, 1.792741, - * 1.164384, -0.213249, -0.532909, - * 1.164384, 2.112402, 0.0000] - */ - [DRM_COLOR_YCBCR_BT709] = { - 0x7E58, 0x7950, 0x0, - 0x8888, 0x7950, 0xADA8, - 0x0, 0x7950, 0x6870, - }, - /* - * BT.2020 Limited range YCbCr -> full range RGB - * The matrix required is : - * [1.164, 0.000, 1.678, - * 1.164, -0.1873, -0.6504, - * 1.164, 2.1417, 0.0000] - */ - [DRM_COLOR_YCBCR_BT2020] = { - 0x7D70, 0x7950, 0x0, - 0x8A68, 0x7950, 0xAC00, - 0x0, 0x7950, 0x6890, - }, - }; - const u16 *csc; - - if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) - csc = input_csc_matrix[plane_state->hw.color_encoding]; - else - csc = input_csc_matrix_lr[plane_state->hw.color_encoding]; + const u16 *csc = input_csc_matrix[plane_state->hw.color_encoding]; intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_COEFF(pipe, plane_id, 0), ROFF(csc[0]) | GOFF(csc[1])); @@ -749,14 +710,8 @@ icl_program_input_csc(struct intel_plane *plane, intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0), PREOFF_YUV_TO_RGB_HI); - if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) - intel_de_write_fw(dev_priv, - PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), - 0); - else - intel_de_write_fw(dev_priv, - PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), - PREOFF_YUV_TO_RGB_ME); + intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), + PREOFF_YUV_TO_RGB_ME); intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2), PREOFF_YUV_TO_RGB_LO); intel_de_write_fw(dev_priv, -- 2.29.2.684.gfbc64c5ab5-goog _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-15 22:42 ` [Intel-gfx] [PATCH v2] " Andres Calderon Jaramillo @ 2021-01-27 23:39 ` Ville Syrjälä 0 siblings, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2021-01-27 23:39 UTC (permalink / raw) To: Andres Calderon Jaramillo Cc: Andres Calderon Jaramillo, intel-gfx, seanpaul, sushma.venkatesh.reddy On Tue, Dec 15, 2020 at 10:42:19PM +0000, Andres Calderon Jaramillo wrote: > 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. This is done by > removing the limited-range code from icl_program_input_csc(). > > 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 > > Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org> Thanks. Slapped a cc:stable on this and pushed. > --- > Changelog since v1: > - Don't skip the YUV range correction stage. Instead, use that stage and > modify icl_program_input_csc() to always assume full-range input. > > drivers/gpu/drm/i915/display/intel_display.c | 2 + > drivers/gpu/drm/i915/display/intel_sprite.c | 65 +++----------------- > 2 files changed, 12 insertions(+), 55 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c > index 761be8deaa9b..8fb9b4f8c1df 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -4811,6 +4811,8 @@ 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; > + if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) > + plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE; > } > > return plane_color_ctl; > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c > index b7e208816074..121e1b5120fd 100644 > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > @@ -633,13 +633,19 @@ skl_program_scaler(struct intel_plane *plane, > > /* Preoffset values for YUV to RGB Conversion */ > #define PREOFF_YUV_TO_RGB_HI 0x1800 > -#define PREOFF_YUV_TO_RGB_ME 0x1F00 > +#define PREOFF_YUV_TO_RGB_ME 0x0000 > #define PREOFF_YUV_TO_RGB_LO 0x1800 > > #define ROFF(x) (((x) & 0xffff) << 16) > #define GOFF(x) (((x) & 0xffff) << 0) > #define BOFF(x) (((x) & 0xffff) << 16) > > +/* > + * Programs the input color space conversion stage for ICL HDR planes. > + * Note that it is assumed that this stage always happens after YUV > + * range correction. Thus, the input to this stage is assumed to be > + * in full-range YCbCr. > + */ > static void > icl_program_input_csc(struct intel_plane *plane, > const struct intel_crtc_state *crtc_state, > @@ -687,52 +693,7 @@ icl_program_input_csc(struct intel_plane *plane, > 0x0, 0x7800, 0x7F10, > }, > }; > - > - /* Matrix for Limited Range to Full Range Conversion */ > - static const u16 input_csc_matrix_lr[][9] = { > - /* > - * BT.601 Limted range YCbCr -> full range RGB > - * The matrix required is : > - * [1.164384, 0.000, 1.596027, > - * 1.164384, -0.39175, -0.812813, > - * 1.164384, 2.017232, 0.0000] > - */ > - [DRM_COLOR_YCBCR_BT601] = { > - 0x7CC8, 0x7950, 0x0, > - 0x8D00, 0x7950, 0x9C88, > - 0x0, 0x7950, 0x6810, > - }, > - /* > - * BT.709 Limited range YCbCr -> full range RGB > - * The matrix required is : > - * [1.164384, 0.000, 1.792741, > - * 1.164384, -0.213249, -0.532909, > - * 1.164384, 2.112402, 0.0000] > - */ > - [DRM_COLOR_YCBCR_BT709] = { > - 0x7E58, 0x7950, 0x0, > - 0x8888, 0x7950, 0xADA8, > - 0x0, 0x7950, 0x6870, > - }, > - /* > - * BT.2020 Limited range YCbCr -> full range RGB > - * The matrix required is : > - * [1.164, 0.000, 1.678, > - * 1.164, -0.1873, -0.6504, > - * 1.164, 2.1417, 0.0000] > - */ > - [DRM_COLOR_YCBCR_BT2020] = { > - 0x7D70, 0x7950, 0x0, > - 0x8A68, 0x7950, 0xAC00, > - 0x0, 0x7950, 0x6890, > - }, > - }; > - const u16 *csc; > - > - if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) > - csc = input_csc_matrix[plane_state->hw.color_encoding]; > - else > - csc = input_csc_matrix_lr[plane_state->hw.color_encoding]; > + const u16 *csc = input_csc_matrix[plane_state->hw.color_encoding]; > > intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_COEFF(pipe, plane_id, 0), > ROFF(csc[0]) | GOFF(csc[1])); > @@ -749,14 +710,8 @@ icl_program_input_csc(struct intel_plane *plane, > > intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0), > PREOFF_YUV_TO_RGB_HI); > - if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE) > - intel_de_write_fw(dev_priv, > - PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), > - 0); > - else > - intel_de_write_fw(dev_priv, > - PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), > - PREOFF_YUV_TO_RGB_ME); > + intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1), > + PREOFF_YUV_TO_RGB_ME); > intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2), > PREOFF_YUV_TO_RGB_LO); > intel_de_write_fw(dev_priv, > -- > 2.29.2.684.gfbc64c5ab5-goog -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-15 20:13 ` Ville Syrjälä 2020-12-15 22:42 ` [Intel-gfx] [PATCH v2] " Andres Calderon Jaramillo @ 2020-12-16 6:46 ` Andres Calderon Jaramillo 2020-12-16 11:18 ` Ville Syrjälä 1 sibling, 1 reply; 14+ messages in thread From: Andres Calderon Jaramillo @ 2020-12-16 6:46 UTC (permalink / raw) To: Ville Syrjälä Cc: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, Venkatesh Reddy, Sushma On Tue, Dec 15, 2020 at 3:13 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Dec 15, 2020 at 03:06:30PM -0500, Andres Calderon Jaramillo wrote: > > On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > > > > On Mon, Dec 14, 2020 at 10:57:03PM +0000, Shankar, Uma wrote: > > > > > > > > > > > > > -----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. > > > > > > Might make sense to actually use the hw range correction instead. > > > Would avoid having to keep around two sets of coefficients. > > > > > > Also the question now becomes: How can our tests be passing if > > > we're doing the range correction twice? > > > > > > > I also considered just removing the limited-range matrix/offsets from > > icl_program_input_csc(). However, I figured that since the "Input CSC" > > stage must happen regardless of range correction, maybe it would be a > > gain to disable the "YUV Range Correction" stage. However, I'm not > > familiar with the hardware details, so I don't know for sure. I don't > > feel strongly either way; let me know what you'd prefer. > > IIRC we use the fixed function range compression + full range csc > approach on chv as well. Wouldn't hurt to do the same thing on > icl+ IMO. Sounds good! Thanks for the review. > > > > > I'm also curious about the testing. How do the tests work? I assume > > they are in Intel's CI and not open sourced? Do they use the DRM > > writeback connector (I didn't think this was implemented for i915 > > yet)? > > Tests are here: > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > > In particular kms_plane/pixel-format tests should rather be failing I > think. Unless we've relaxed things a bit too much to get the crcs to > match when the results are close enough. > Nice. I took a look at the tests you referenced. It seems that we may have just gotten unlucky with the color choice, but I'm not sure why (I kind of expected to still get a color difference with the current colors). I tried changing the color in [1] to {0.0f, 0.2f, 0.2f}, and I got "CRC mismatches" failures for multiple formats including NV12, C8, and YUYV. Interestingly, I had tried something like this multiple times, and I couldn't get the CRC mismatch at first. I don't know what changed. Maybe the mode was in a bad state and when I rebooted the device, it was good. Note, with that color change and with this patch, I still get "CRC mismatches" failures but only for C8. I'm unfamiliar with that format, but it seems like a different problem. [1] https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/igt-gpu-tools/tests/kms_plane.c;l=383;drc=c8a9aa95e2c5c8d9d39f4f9388a7d602a2e64311 > > > > > > > > > > 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 > > > > > > -- > > > Ville Syrjälä > > > Intel > > -- > Ville Syrjälä > Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes 2020-12-16 6:46 ` [Intel-gfx] [PATCH] " Andres Calderon Jaramillo @ 2020-12-16 11:18 ` Ville Syrjälä 0 siblings, 0 replies; 14+ messages in thread From: Ville Syrjälä @ 2020-12-16 11:18 UTC (permalink / raw) To: Andres Calderon Jaramillo Cc: Andres Calderon Jaramillo, intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, Venkatesh Reddy, Sushma On Wed, Dec 16, 2020 at 01:46:58AM -0500, Andres Calderon Jaramillo wrote: > On Tue, Dec 15, 2020 at 3:13 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Dec 15, 2020 at 03:06:30PM -0500, Andres Calderon Jaramillo wrote: > > > On Tue, Dec 15, 2020 at 1:01 PM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > On Mon, Dec 14, 2020 at 10:57:03PM +0000, Shankar, Uma wrote: > > > > > > > > > > > > > > > > -----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. > > > > > > > > Might make sense to actually use the hw range correction instead. > > > > Would avoid having to keep around two sets of coefficients. > > > > > > > > Also the question now becomes: How can our tests be passing if > > > > we're doing the range correction twice? > > > > > > > > > > I also considered just removing the limited-range matrix/offsets from > > > icl_program_input_csc(). However, I figured that since the "Input CSC" > > > stage must happen regardless of range correction, maybe it would be a > > > gain to disable the "YUV Range Correction" stage. However, I'm not > > > familiar with the hardware details, so I don't know for sure. I don't > > > feel strongly either way; let me know what you'd prefer. > > > > IIRC we use the fixed function range compression + full range csc > > approach on chv as well. Wouldn't hurt to do the same thing on > > icl+ IMO. > > Sounds good! Thanks for the review. > > > > > > > > > I'm also curious about the testing. How do the tests work? I assume > > > they are in Intel's CI and not open sourced? Do they use the DRM > > > writeback connector (I didn't think this was implemented for i915 > > > yet)? > > > > Tests are here: > > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > > > > In particular kms_plane/pixel-format tests should rather be failing I > > think. Unless we've relaxed things a bit too much to get the crcs to > > match when the results are close enough. > > > > Nice. I took a look at the tests you referenced. It seems that we may > have just gotten unlucky with the color choice, but I'm not sure why > (I kind of expected to still get a color difference with the current > colors). Hmm. I guess we need to think a bit more about the colors used. > I tried changing the color in [1] to {0.0f, 0.2f, 0.2f}, and > I got "CRC mismatches" failures for multiple formats including NV12, > C8, and YUYV. Interestingly, I had tried something like this multiple > times, and I couldn't get the CRC mismatch at first. I don't know what > changed. Maybe the mode was in a bad state and when I rebooted the > device, it was good. > > Note, with that color change and with this patch, I still get "CRC > mismatches" failures but only for C8. I'm unfamiliar with that format, > but it seems like a different problem. We render the image as RGB332 for C8 so it can only have 2^3 or 2^2 levels. Whereas for the 8bpc reference image we only chop off the results to 5 msbs with the LUT, which gets us 2^5 levels. So the choice of color would have to be constrained to fit the RGB332 limits to get the same output for both. > > [1] https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/igt-gpu-tools/tests/kms_plane.c;l=383;drc=c8a9aa95e2c5c8d9d39f4f9388a7d602a2e64311 > > > > > > > > > > > > > > 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 > > > > > > > > -- > > > > Ville Syrjälä > > > > Intel > > > > -- > > Ville Syrjälä > > Intel -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Prevent double YUV range correction on HDR planes 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 @ 2020-12-15 20:59 ` Patchwork 2020-12-15 21:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork ` (3 subsequent siblings) 5 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2020-12-15 20:59 UTC (permalink / raw) To: Andres Calderon Jaramillo; +Cc: intel-gfx == Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes URL : https://patchwork.freedesktop.org/series/84966/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7f602d3a40e4 drm/i915/display: Prevent double YUV range correction on HDR planes -:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #23: [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281 total: 0 errors, 1 warnings, 0 checks, 13 lines checked _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Prevent double YUV range correction on HDR planes 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 2020-12-15 20:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork @ 2020-12-15 21:29 ` 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 ` (2 subsequent siblings) 5 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2020-12-15 21:29 UTC (permalink / raw) To: Andres Calderon Jaramillo; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 3828 bytes --] == Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes URL : https://patchwork.freedesktop.org/series/84966/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9488 -> Patchwork_19149 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_19149 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19149, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/index.html Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_19149: ### IGT changes ### #### Possible regressions #### * igt@gem_exec_suspend@basic-s3: - fi-snb-2600: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-snb-2600/igt@gem_exec_suspend@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-snb-2600/igt@gem_exec_suspend@basic-s3.html Known issues ------------ Here are the changes found in Patchwork_19149 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271]) +22 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-bdw-5557u/igt@amdgpu/amd_basic@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-bdw-5557u/igt@core_hotunplug@unbind-rebind.html * igt@prime_self_import@basic-with_one_bo_two_files: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html * igt@runner@aborted: - fi-snb-2600: NOTRUN -> [FAIL][7] ([i915#698]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-snb-2600/igt@runner@aborted.html #### Possible fixes #### * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][8] ([i915#402]) -> [PASS][9] +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9488/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#698]: https://gitlab.freedesktop.org/drm/intel/issues/698 Participating hosts (43 -> 39) ------------------------------ Missing (4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes ------------- * Linux: CI_DRM_9488 -> Patchwork_19149 CI-20190529: 20190529 CI_DRM_9488: 610a032e0c8eff40d87d9344f92311382f4acd49 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5901: 565d911f08df697fa211dbd1faefe2fd57066f71 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19149: 7f602d3a40e441cbaf5fa895c639562bcf82d4de @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7f602d3a40e4 drm/i915/display: Prevent double YUV range correction on HDR planes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19149/index.html [-- Attachment #1.2: Type: text/html, Size: 4648 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) 2020-12-14 22:19 [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes Andres Calderon Jaramillo ` (2 preceding siblings ...) 2020-12-15 21:29 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork @ 2020-12-16 0:51 ` Patchwork 2020-12-16 1:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2020-12-16 7:54 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 5 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2020-12-16 0:51 UTC (permalink / raw) To: Andres Calderon Jaramillo; +Cc: intel-gfx == Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) URL : https://patchwork.freedesktop.org/series/84966/ State : warning == Summary == $ dim checkpatch origin/drm-tip c3629bb8e645 drm/i915/display: Prevent double YUV range correction on HDR planes -:24: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #24: [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281 total: 0 errors, 1 warnings, 0 checks, 97 lines checked _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) 2020-12-14 22:19 [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes Andres Calderon Jaramillo ` (3 preceding siblings ...) 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 ` Patchwork 2020-12-16 7:54 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 5 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2020-12-16 1:20 UTC (permalink / raw) To: Andres Calderon Jaramillo; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 3775 bytes --] == Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) URL : https://patchwork.freedesktop.org/series/84966/ State : success == Summary == CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19152 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/index.html Known issues ------------ Here are the changes found in Patchwork_19152 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-snb-2600: NOTRUN -> [SKIP][1] ([fdo#109271]) +30 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-snb-2600: NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@kms_chamelium@hdmi-crc-fast.html * igt@kms_psr@primary_page_flip: - fi-glk-dsi: NOTRUN -> [SKIP][3] ([fdo#109271]) +21 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-glk-dsi/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-write: - fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_vgem@basic-write.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-tgl-y/igt@prime_vgem@basic-write.html #### Possible fixes #### * igt@gem_exec_suspend@basic-s3: - fi-snb-2600: [DMESG-WARN][6] -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_suspend@basic-s3.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-snb-2600/igt@gem_exec_suspend@basic-s3.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-glk-dsi: [INCOMPLETE][8] ([i915#2377]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-glk-dsi/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][10] ([i915#402]) -> [PASS][11] +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 39) ------------------------------ Missing (4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes ------------- * Linux: CI_DRM_9489 -> Patchwork_19152 CI-20190529: 20190529 CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19152: c3629bb8e645760ce4d1e6bae19781c24d4cefe8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c3629bb8e645 drm/i915/display: Prevent double YUV range correction on HDR planes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/index.html [-- Attachment #1.2: Type: text/html, Size: 4749 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) 2020-12-14 22:19 [Intel-gfx] [PATCH] drm/i915/display: Prevent double YUV range correction on HDR planes Andres Calderon Jaramillo ` (4 preceding siblings ...) 2020-12-16 1:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork @ 2020-12-16 7:54 ` Patchwork 5 siblings, 0 replies; 14+ messages in thread From: Patchwork @ 2020-12-16 7:54 UTC (permalink / raw) To: Andres Calderon Jaramillo; +Cc: intel-gfx [-- Attachment #1.1: Type: text/plain, Size: 18217 bytes --] == Series Details == Series: drm/i915/display: Prevent double YUV range correction on HDR planes (rev2) URL : https://patchwork.freedesktop.org/series/84966/ State : success == Summary == CI Bug Log - changes from CI_DRM_9489_full -> Patchwork_19152_full ==================================================== Summary ------- **SUCCESS** No regressions found. Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_19152_full: ### IGT changes ### #### Suppressed #### The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. * {igt@gem_exec_balancer@fairslice}: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb3/igt@gem_exec_balancer@fairslice.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb1/igt@gem_exec_balancer@fairslice.html * {igt@gem_exec_schedule@u-fairslice@vcs1}: - shard-tglb: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb7/igt@gem_exec_schedule@u-fairslice@vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb7/igt@gem_exec_schedule@u-fairslice@vcs1.html Known issues ------------ Here are the changes found in Patchwork_19152_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#180]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl2/igt@gem_ctx_isolation@preservation-s3@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl3/igt@gem_ctx_isolation@preservation-s3@vcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2389]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb1/igt@gem_exec_reloc@basic-wide-active@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][8] -> [SKIP][9] ([i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb5/igt@gem_huc_copy@huc-copy.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb6/igt@gem_huc_copy@huc-copy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][10] ([i915#2658]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@gem_pread@exhaustion.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl1/igt@gem_render_copy@linear-to-vebox-y-tiled.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][12] -> [INCOMPLETE][13] ([i915#151]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@i915_pm_rpm@system-suspend.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl3/igt@i915_pm_rpm@system-suspend.html * igt@kms_big_fb@x-tiled-32bpp-rotate-90: - shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk9/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html * igt@kms_color_chamelium@pipe-a-ctm-red-to-blue: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@kms_color_chamelium@pipe-a-ctm-red-to-blue.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#54]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl10/igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl7/igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#72]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk5/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][20] -> [FAIL][21] ([i915#79]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html * igt@kms_flip@flip-vs-suspend@c-hdmi-a1: - shard-hsw: [PASS][22] -> [INCOMPLETE][23] ([i915#2055]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-hsw4/igt@kms_flip@flip-vs-suspend@c-hdmi-a1.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-hsw6/igt@kms_flip@flip-vs-suspend@c-hdmi-a1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move: - shard-iclb: [PASS][24] -> [FAIL][25] ([i915#49]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb3/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb2/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-move.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][26] -> [FAIL][27] ([i915#1188]) [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_hdr@bpc-switch-suspend.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl1/igt@kms_hdr@bpc-switch-suspend.html * igt@kms_plane_lowres@pipe-a-tiling-none: - shard-kbl: [PASS][28] -> [DMESG-WARN][29] ([i915#165] / [i915#180] / [i915#78]) [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl7/igt@kms_plane_lowres@pipe-a-tiling-none.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl2/igt@kms_plane_lowres@pipe-a-tiling-none.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][30] -> [SKIP][31] ([fdo#109441]) +1 similar issue [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html * igt@perf@polling-parameterized: - shard-tglb: [PASS][32] -> [FAIL][33] ([i915#1542]) [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb7/igt@perf@polling-parameterized.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb8/igt@perf@polling-parameterized.html * igt@prime_vgem@fence-write-hang: - shard-apl: NOTRUN -> [SKIP][34] ([fdo#109271]) +12 similar issues [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@prime_vgem@fence-write-hang.html #### Possible fixes #### * igt@drm_mm@all@evict: - shard-skl: [INCOMPLETE][35] ([i915#2295]) -> [PASS][36] [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl4/igt@drm_mm@all@evict.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl9/igt@drm_mm@all@evict.html * igt@gem_exec_flush@basic-batch-kernel-default-uc: - shard-glk: [DMESG-WARN][37] ([i915#118] / [i915#95]) -> [PASS][38] [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk2/igt@gem_exec_flush@basic-batch-kernel-default-uc.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk4/igt@gem_exec_flush@basic-batch-kernel-default-uc.html * {igt@gem_exec_schedule@u-fairslice@vcs0}: - shard-apl: [DMESG-WARN][39] ([i915#1610]) -> [PASS][40] [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl7/igt@gem_exec_schedule@u-fairslice@vcs0.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl2/igt@gem_exec_schedule@u-fairslice@vcs0.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-hsw: [WARN][41] ([i915#1519]) -> [PASS][42] [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-hsw4/igt@i915_pm_rc6_residency@rc6-idle.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-hsw6/igt@i915_pm_rc6_residency@rc6-idle.html * igt@i915_selftest@live@active: - shard-skl: [DMESG-FAIL][43] ([i915#2291]) -> [PASS][44] [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl9/igt@i915_selftest@live@active.html [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl9/igt@i915_selftest@live@active.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-skl: [FAIL][45] ([i915#2521]) -> [PASS][46] [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@kms_async_flips@alternate-sync-async-flip.html [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html - shard-kbl: [FAIL][47] ([i915#2521]) -> [PASS][48] [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl7/igt@kms_async_flips@alternate-sync-async-flip.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl2/igt@kms_async_flips@alternate-sync-async-flip.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [FAIL][49] ([i915#2597]) -> [PASS][50] [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb1/igt@kms_async_flips@test-time-stamp.html [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb2/igt@kms_async_flips@test-time-stamp.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [FAIL][51] ([i915#54]) -> [PASS][52] +3 similar issues [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl5/igt@kms_cursor_crc@pipe-c-cursor-suspend.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [INCOMPLETE][53] ([i915#146] / [i915#198]) -> [PASS][54] [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl1/igt@kms_fbcon_fbt@psr-suspend.html [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl4/igt@kms_fbcon_fbt@psr-suspend.html * igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2: - shard-glk: [INCOMPLETE][55] -> [PASS][56] [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk7/igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2.html [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk9/igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1: - shard-hsw: [FAIL][57] ([i915#2122]) -> [PASS][58] [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-hsw6/igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1.html [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-hsw4/igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1.html * igt@kms_flip@plain-flip-fb-recreate@b-edp1: - shard-skl: [FAIL][59] ([i915#2122]) -> [PASS][60] +1 similar issue [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl8/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt: - shard-glk: [FAIL][61] ([i915#49]) -> [PASS][62] [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk5/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt.html [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-glk7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [FAIL][63] ([i915#1188]) -> [PASS][64] [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl10/igt@kms_hdr@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [FAIL][65] ([fdo#108145] / [i915#265]) -> [PASS][66] [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html * {igt@perf@non-zero-reason}: - shard-iclb: [FAIL][67] -> [PASS][68] [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb5/igt@perf@non-zero-reason.html [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb3/igt@perf@non-zero-reason.html #### Warnings #### * igt@runner@aborted: - shard-kbl: [FAIL][69] ([i915#2295] / [i915#2722] / [i915#483]) -> ([FAIL][70], [FAIL][71]) ([i915#1436] / [i915#2295] / [i915#2722] / [i915#483]) [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl4/igt@runner@aborted.html [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl3/igt@runner@aborted.html [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-kbl4/igt@runner@aborted.html - shard-iclb: [FAIL][72] ([i915#2295] / [i915#2722] / [i915#2724] / [i915#483]) -> [FAIL][73] ([i915#2295] / [i915#2722] / [i915#2724]) [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb6/igt@runner@aborted.html [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-iclb4/igt@runner@aborted.html - shard-apl: ([FAIL][74], [FAIL][75]) ([i915#1610] / [i915#2295] / [i915#2426] / [i915#2722]) -> [FAIL][76] ([i915#2295] / [i915#2722]) [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl7/igt@runner@aborted.html [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl8/igt@runner@aborted.html [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-apl8/igt@runner@aborted.html - shard-tglb: [FAIL][77] ([i915#2295] / [i915#2722]) -> ([FAIL][78], [FAIL][79]) ([i915#2295] / [i915#2426] / [i915#2722]) [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb2/igt@runner@aborted.html [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb7/igt@runner@aborted.html [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/shard-tglb5/igt@runner@aborted.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118 [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#1519]: https://gitlab.freedesktop.org/drm/intel/issues/1519 [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542 [i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180 [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198 [i915#2055]: https://gitlab.freedesktop.org/drm/intel/issues/2055 [i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295 [i915#2389]: https://gitlab.freedesktop.org/drm/intel/issues/2389 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521 [i915#2597]: https://gitlab.freedesktop.org/drm/intel/issues/2597 [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265 [i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#2724]: https://gitlab.freedesktop.org/drm/intel/issues/2724 [i915#483]: https://gitlab.freedesktop.org/drm/intel/issues/483 [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49 [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54 [i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72 [i915#78]: https://gitlab.freedesktop.org/drm/intel/issues/78 [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (10 -> 10) ------------------------------ No changes in participating hosts Build changes ------------- * Linux: CI_DRM_9489 -> Patchwork_19152 CI-20190529: 20190529 CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19152: c3629bb8e645760ce4d1e6bae19781c24d4cefe8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19152/index.html [-- Attachment #1.2: Type: text/html, Size: 21719 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-01-27 23:39 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox