The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* TGL:  igt@kms_flip_tiling@* - fail - Failed assertion: ret == 0
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7104/re-tgl-u/igt@kms_flip_tiling@flip-to-y-tiled.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7104/re-tgl-u/igt@kms_flip_tiling@flip-y-tiled.html

<7> [429.032901] [drm:skl_allocate_pipe_ddb [i915]] Requested display configuration exceeds system DDB limitations
<7> [429.032960] [drm:skl_allocate_pipe_ddb [i915]] minimum required 243/238

That seems somewhat suspicious given that we don't seem to be trying to use a bunch of planes+connectors here.

Can you provide the contents of:
  /sys/kernel/debug/dri/0/i915_display_info.txt
  /sys/kernel/debug/dri/0/i915_ddb_info
  /sys/kernel/debug/dri/0/i915_pri_wm_latency

Created attachment 145839 [details]
Requested info

Requested info attached

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.

(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?

In the short term it can be worked around in IGT by making sure the tests disable resources they aren't actively using.  However arguably the more important "fix" will be https://patchwork.freedesktop.org/series/67771/ (and equivalent enablement for TGL) which will double the effective resources available for the driver to use.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/538.