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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Oct 30 18:13:04 UTC 2019


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW
           Priority|not set                     |medium
           Severity|not set                     |normal

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee 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/20191030/89b93425/attachment.html>


More information about the intel-gfx-bugs mailing list