[Bug 106885] [CI] igt at kms_plane@pixel-format-pipe-[abc]-planes - dmesg-warn - *ERROR* Overflow of CRC buffer, userspace reads too slow.

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Juha-Pekka Heikkilä <juhapekka.heikkila at gmail.com> ---
(In reply to Martin Peres from comment #7)
> (In reply to Mika Kahola from comment #6)
> > If this error is not seen regularly, maybe we could pump up a bit the size
> > of a ringbuffer. Now, we have DRM_CRC_ENTRIES_NR defined as 128, so maybe we
> > could increase it to 256?
> 
> Are the CRCs per pipe or global? If it is per-pipe, then 128 CRCs @ 60 Hz is
> more than 2 seconds of not reading the crc... I would think that this ought
> to be sufficient and if it is not, we really need to look into why we have
> such latency in the userspace, don't you think? :o

The latency would be from the combination of things; IGT by default is compiled
with no optimizations switched on, used framebuffer sizes are quite big
(3840x2160 for example), and because lack of YUV support in cairo there's in
IGT conversions back'n'forth RGB<->YUV..all this combined probably can build up
to 2s wait.

One could try putting some "#pragma GCC optimize ("O3")" around those
conversion functions "static void convert_XXX_to_XXX(struct fb_convert *cvt)"
found in igt_fb.c, though I think this is just painting over the problem.

Other solution would be starting/stopping crc when crc is really needed but it
would slow down tests in kms_plane even more.

-- 
You are receiving this mail because:
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/20181213/ef1a2d44/attachment-0001.html>