[Bug 112092] [CI][RESUME] igt at kms_flip_tiling@* - fail - Failed assertion: ret == 0

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Lakshmi <lakshminarayana.vudum at intel.com> ---
(In reply to Matt Roper from comment #4)
> Okay, it looks like we have 3 very large displays attached, so maybe this
> failure is legitimate.  TGL has 2048 DDB blocks split across two DBUF's, but
> today our driver only supports a single DBUF so we only have 1024 available
> to us.  That buffer allocation needs to be split between the active pipes
> and according to display_info you have 3 pipes active with modes 4k, 4k, 5k.
> The ddb is partitioned proportional to the display data rates, so your pipes
> get 307, 307, 410 respectively.  Some of those blocks are reserved for use
> by the cursor plane, so on pipe A (where the failure arose) we had 238
> blocks left to drive the primary plane (and any sprites we might have wanted
> to turn on).  For a large 4k display, 238 doesn't seem too unreasonable (the
> exact requirements depend on a bunch of variables, including the latency of
> the RAM your platform is using so it's not easy to calculate by hand without
> a spreadsheet).  So I suspect everything is actually working as expected and
> we simply don't have the resources necessary to satisfy IGT's request here
> (flipping to Y-tiled buffers generally requires more DDB than
> linear/x-tiled).
> 
> A lot of the DDB pressure here comes from the fact that we don't yet enable
> the second DBUF that's availabe on ICL+.  Stanislav is working on some
> patches to address that now, so the situation will likely improve soon and
> we'll be able to avoid running out of DDB space on large monitors unless we
> also try to turn on lots of planes too.
> 
> So the failure returned by the kernel here is correct/expected; in theory a
> sophisticated userspace compositor would react to this failure by retrying
> with a less aggressive display setup (possibly reducing the resolution of
> monitor(s)) until the configuration could be satisfied.  Also, the situation
> isn't really any worse than we already have on ICL or before, so marking
> this as medium priority/exposure.
> 
> Since IGT isn't sophisticated enough to retry with less aggressive
> configurations when DDB exhaustion occurs, we could probably avoid these
> kind of issues by updating this test (and any others that hit similar DDB
> exhaustion) to make sure they turn off any pipes they aren't explicitly
> trying to use before they start their testing.  That would allow i915 to
> give the full platform DDB allocation of 1024 blocks to the one active pipe,
> meaning we'd have plenty of blocks to run this test without running out.

Matt, this issue should be under IGT?

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