https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4988/shard-skl5/igt@kms_color@pipe-a-ctm-green-to-red.html

Starting subtest: pipe-A-ctm-green-to-red
(kms_color:888) CRITICAL: Test assertion failure function run_tests_for_pipe, file ../tests/kms_color.c:902:
(kms_color:888) CRITICAL: Failed assertion: test_pipe_ctm(data, primary, red_green_blue, red_red_blue, ctm)
Subtest pipe-A-ctm-green-to-red failed.

Also seen on KBL: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_130/fi-kbl-r/igt@kms_color@pipe-a-ctm-blue-to-red.html

Starting subtest: pipe-A-ctm-blue-to-red
(kms_color:1548) CRITICAL: Test assertion failure function run_tests_for_pipe, file ../tests/kms_color.c:915:
(kms_color:1548) CRITICAL: Failed assertion: test_pipe_ctm(data, primary, red_green_blue, red_green_red, ctm)
Subtest pipe-A-ctm-blue-to-red failed.

Also seen on aBXT: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_140/fi-bxt-dsi/igt@kms_color@pipe-c-ctm-blue-to-red.html

Starting subtest: pipe-C-ctm-blue-to-red
(kms_color:2162) CRITICAL: Test assertion failure function run_tests_for_pipe, file ../tests/kms_color.c:915:
(kms_color:2162) CRITICAL: Failed assertion: test_pipe_ctm(data, primary, red_green_blue, red_green_red, ctm)
Subtest pipe-C-ctm-blue-to-red failed.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5257/shard-skl10/igt@kms_color@pipe-a-ctm-red-to-blue.html

Starting subtest: pipe-A-ctm-red-to-blue
(kms_color:2119) CRITICAL: Test assertion failure function run_tests_for_pipe, file ../tests/kms_color.c:889:
(kms_color:2119) CRITICAL: Failed assertion: test_pipe_ctm(data, primary, red_green_blue, blue_green_blue, ctm)
Subtest pipe-A-ctm-red-to-blue failed.

A CI Bug Log filter associated to this bug has been updated:

{- BXT APL SKL KBL: igt@kms_color@pipe-[abc]-ctm-$color-to-$color - fail - Failed assertion: test_pipe_ctm(data, primary, red_green_blue, .*, ctm) -}
{+ BXT APL SKL KBL WHL: igt@kms_color@pipe-[abc]-ctm-$color-to-$color - fail - Failed assertion: test_pipe_ctm(data, primary, red_green_blue, .*, ctm) +}

New failures caught by the filter:

* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_159/fi-whl-u/igt@kms_color@pipe-c-ctm-red-to-blue.html
* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_159/fi-whl-u/igt@kms_color@pipe-c-ctm-green-to-red.html
* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_168/fi-whl-u/igt@kms_color@pipe-a-ctm-blue-to-red.html
* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_180/fi-whl-u/igt@kms_color@pipe-a-ctm-green-to-red.html
* https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_181/fi-whl-u/igt@kms_color@pipe-a-ctm-green-to-red.html

A CI Bug Log filter associated to this bug has been updated:

{- BXT APL SKL KBL WHL: igt@kms_color@pipe-[abc]-ctm-$color-to-$color - fail - Failed assertion: test_pipe_ctm(data, primary, red_green_blue, .*, ctm) -}
{+ BXT APL SKL KBL WHL CFL: igt@kms_color@pipe-[abc]-ctm-$color-to-$color - fail - Failed assertion: test_pipe_ctm(data, primary, red_green_blue, .*, ctm) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_289/fi-cfl-8109u/igt@kms_color@pipe-b-ctm-green-to-red.html
  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_289/fi-cfl-8700k/igt@kms_color@pipe-b-ctm-green-to-red.html
  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_289/fi-cfl-guc/igt@kms_color@pipe-b-ctm-green-to-red.html

This test is exercising the 'ctm' CRTC property which controls the color transformation matrix applied to pipe output.  Specifically these failing subtests use matrices that will translate 100% of one color component into a different color component; this is done by starting with an identity matrix but shifting the '1' from the desired component column into a different column.  E.g., to translate the red component into blue, a matrix of

  [ 0 0 1 ]
  [ 0 1 0 ]
  [ 0 0 1 ]

is used.  The test first draws a framebuffer containing the desired transformation applied by software *without* using the hardware CTM, takes a CRC, then draws a non-transformed framebuffer with the hardware CTM applied, and takes another CRC.  Both CRC's should be equivalent (i.e., the hardware CTM translates the framebuffer in the same way software transformation does) and the test fails if they do not match.

It would be good if someone with a relevant hardware platform (any gen9 seems to be suitable here) could reproduce this and visually check what the colors look like on-screen.  I.e., is the transformation not taking effect at all, or is it just a rounding error that causes the colors to come out slightly differently, but is generally imperceptible to the human eye?  I do wonder whether we should disable gamma/degamma LUT's (instead of explicitly applying linear tables) in all cases rather than just when the original matrix and target matrix are not the same; I wouldn't expect the LUT's to be an issue with all-1.0 color values, but maybe there's some additional hardware rounding that still slightly throws it off.

I do note that these subtests create an 'fb_modeset' framebuffer which is never used.  I suspect this is a copy/paste artifact from a different subtest; the creation of this extra fb is unnecessary and could be removed, but shouldn't have any negative impact on the test results.

The failure has been caught on 10.5% of the tests run, which is down from the original reproduction rate of 20.2%.  The last seen failure happened 2.5 weeks ago.

These color management properties (CTM as well as gamma/degamma) are generally used at higher levels of the stack to adjust output colors in a way that works well for the target monitor.  If they aren't working as expected, the colors may be slightly off from what was desired, but the system will still be usable.  And if the failures here are just rounding error (as color management issues often are), then there's a good chance that the color deltas between desired and actual won't even be something an end user can perceive.  Thus I think it's justified to drop the priority of this bug to medium.  Also adding Uma to the Cc list since he's the expert on color management and may have additional ideas.

Very nicely explained by Matt, this is exactly how these tests are designed and expected to behave.

However for these random failures-
This is in general a static behavior, the test if passed in 1 run should pass on stress as well. If any roundup or interpolation error is there, then it should come for every run.

Since on the hardware highlighted in this Bugzilla it passes most of the time and fails in <10%, this points to some inconsistent update or a failed evasion, underrun etc. If any of this happens we may get a wrong crc and match will fail.

So ideally this is not a color related issue as such but atomic update, underrun related behavior causing this test to fail inconsistently.

Lets keep an eye on this issue with medium priority and bump up in case we see
consistent failures.

Note: There are failures in color test with ICL+ hardware and multi segmented gamma (high precision gamma), but that occurs consistently i/e all the time (100% reproducible). Those issues are being analyzed to find some WA and are being tracked separately.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/129.