<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][RESUME] igt@kms_flip_tiling@* - fail - Failed assertion: ret == 0" href="https://bugs.freedesktop.org/show_bug.cgi?id=112092#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][RESUME] igt@kms_flip_tiling@* - fail - Failed assertion: ret == 0" href="https://bugs.freedesktop.org/show_bug.cgi?id=112092">bug 112092</a> from <a class="email" href="mailto:lakshminarayana.vudum@intel.com" title="Lakshmi <lakshminarayana.vudum@intel.com>"> Lakshmi</a> <pre>(In reply to Matt Roper from <a href="show_bug.cgi?id=112092#c4">comment #4</a>) > 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>