[Bug 108303] [CI][DRMTIP] igt at kms_flip_tiling@flip-(y-tiled|changes-tiling(-yf?)?) - fail - Failed assertion: !mismatch

[bugzilla-daemon at freedesktop.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      i915 platform|                            |BYT
                 CC|                            |matthew.d.roper at intel.com

--- Comment #21 from Matt Roper <matthew.d.roper at intel.com> ---
igt at kms_flip_tiling@flip-changes-tiling is also failing on BYT; that was
previously tracked separately in bug 107831, but based on the output it looks
like it's probably the same underlying issue; adding BYT to the platform list
here and marking the other one as a duplicate.

As Lakshmi mentioned, this test is trying to test pageflip transitions from one
tiling format to another during legacy pageflips.  It does so by allocating two
framebuffers, fb0 and fb1.  The test first does a modeset to place fb1 on the
screen and takes a reference CRC.  It then does a modeset to put fb0 on the
screen (which contains a different image than fb1 so the CRC is unlikely to
match at this point).  Finally, it performs a legacy pageflip to switch back to
fb1 again and takes another CRC.  This CRC should match the original reference
CRC, but the the test is failing because it does not.

One interesting thing to note is that this test uses oversized framebuffers and
primary planes (e.g., 2048 wide when running on a 1366 width display) to make
it easy to find framebuffer sizes with compatible strides.  That should be
perfectly legal and not cause problems (the primary plane will just be clipped
back to the size of the pipe), but since it is an unusual situation, that might
be a good place to start investigating to see whether we're doing anything
wrong in the driver's clipping that might lead to a CRC mismatch.

Another thing to double confirm if someone has a platform to test this on
directly would be that we truly are waiting for flip completion properly and
not just assuming that fb1 will be back on the screen the next vblank after we
submit the flip.  The code for that looks correct to me (we don't ask for
vblank events so pageflip completions should be the only thing we can read from
the DRM filehandle), but if there's something I'm overlooking and we're
actually taking the CRC after a vblank event rather than a pageflip completion
event, then we could run into problems if the pageflip were submitted during
the vblank evasion window (i.e., the driver would wait for a vblank to complete
before actually updating the plane registers, and the new framebuffer wouldn't
actually be visible on screen until the next vblank after that).  Again, the
code looks correct to me, but it would be good for someone with actual hardware
to confirm that this definitely isn't the source of the problem.

It would also probably be good to update this test to include atomic variants
of these tests.  It would be a useful data point to know whether we get the
same kind of failures for flips submitted via the atomic API as through the
legacy pageflip API.

As Lakshmi mentioned, the impact of this failure should be relatively low on
real-world use cases.  This test is more focused on ensuring we're covering the
corner cases of the ABI rather than modeling a situation that comes up
frequently in real-world usage.  That's especially true given that this test is
still using the legacy pageflip ioctl rather than performing atomic updates
like a lot of modern userspace would.

-- 
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/20190904/c9dc8a43/attachment-0001.html>