[Bug 107201] [CI][SHARDS] igt at kms_color@pipe-[abc]-ctm-$color-to-$color - fail - Failed assertion: test_pipe_ctm(data, primary, red_green_blue, .*, ctm)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107201

Matt Roper <matthew.d.roper at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uma.shankar at intel.com
           Priority|high                        |medium

--- Comment #7 from Matt Roper <matthew.d.roper at intel.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190820/040f85b6/attachment.html>