Bug 111995 - [KBL] Black screen with I915_FORMAT_MOD_Y_TILED_CCS (Requested display configuration exceeds system DDB limitations)
Summary: [KBL] Black screen with I915_FORMAT_MOD_Y_TILED_CCS (Requested display config...
Status: RESOLVED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: not set not set
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-14 10:46 UTC by emersion
Modified: 2019-10-25 16:01 UTC (History)
2 users (show)

See Also:
i915 platform: KBL
i915 features:

Attachments

Description emersion 2019-10-14 10:46:47 UTC 
This is a bug report for a KBL machine. This issue can be reproduce on both Sway [1] and Weston. The Sway issue contains a DRM dmesg excerpt.

User-space tries to enable a pipe with a 3840x2160 XRGB8888 buffer. The buffer is created with gbm_surface_create_with_modifiers. The primary plane supports I915_FORMAT_MOD_Y_TILED_CCS, it seems like that's what the driver is picking.

However when scanning out the buffer, the driver bails out with "Requested display configuration exceeds system DDB limitations". This results in a black screen.

My main question is: both Weston and wlroots except gbm_surface_create_with_modifiers to pick a modifier so that the buffer can be scanned out [2]. I wouldn't expect the driver to pick a modifier that doesn't work.

If this isn't a driver bug, should user-space force LINEAR if the atomic commit fails? Should it prune the modifier and retry with gbm_surface_create_with_modifiers?

[1]: https://github.com/swaywm/wlroots/issues/1852
[2]: https://github.com/swaywm/wlroots/blob/480a31ea4e1a3aadbd053ee2a581cad5d4356876/backend/drm/renderer.c#L87
Comment 1 Ville Syrjala 2019-10-14 13:44:23 UTC 
The DDB stuff depends on dotclock, number of pipes/planes, plane size, plane/pipe scaling, etc. so there is no real way to know upfront whether a particular framebuffer can be scanned out or not.

There should probably be some kind of mechanism to fall back to X-tiled if Y/Y+CCS fails.

In this particular case it's not entirely clear why it fails though. A full log would help. And probably we would want the following addition as well:

--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4401,6 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state,
                DRM_DEBUG_KMS("Requested display configuration exceeds system DDB limitations");
                DRM_DEBUG_KMS("minimum required %d/%d\n", blocks,
                              alloc_size);
+               skl_print_wm_changes(to_intel_atomic_state(state));
                return -EINVAL;
        }
Comment 2 Marius Vlad 2019-10-18 22:22:22 UTC 
Hmm, I always get that when trying to use both planes, but when using AR24. XR24 works just fine on scan-out (primary)


[51903.929518] [drm:skl_allocate_pipe_ddb [i915]] Requested display configuration exceeds system DDB limitations
[51903.929551] [drm:skl_allocate_pipe_ddb [i915]] minimum required 964/847
[51903.929584] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000004889d62d failed: -22
[51903.929615] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000004889d62d

but even so, weston is able to continue just fine switching to mixed mode of compositing

[atomic] drmModeAtomicCommit
                [view] failing state generation: atomic test not OK
        [repaint] could not build planes-only state, trying mixed

For reference this seems to happen when using AR24 on scan-out not XR24 (which I tested many times before). 

Here's the current state of both planes, before doing the TEST_ONLY bit. 

                        [CRTC:47] 22 (MODE_ID) -> 120 (0x78)
                        [CRTC:47] 21 (ACTIVE) -> 1 (0x1)
                        [CONN:85] 19 (CRTC_ID) -> 47 (0x2f)
                        [PLANE:37] 16 (FB_ID) -> 122 (0x7a)
                        [PLANE:37] 19 (CRTC_ID) -> 47 (0x2f)
                        [PLANE:37] 8 (SRC_X) -> 0 (0x0)
                        [PLANE:37] 9 (SRC_Y) -> 0 (0x0)
                        [PLANE:37] 10 (SRC_W) -> 251658240 (0xf000000)
                        [PLANE:37] 11 (SRC_H) -> 141557760 (0x8700000)
                        [PLANE:37] 12 (CRTC_X) -> 0 (0x0)
                        [PLANE:37] 13 (CRTC_Y) -> 0 (0x0)
                        [PLANE:37] 14 (CRTC_W) -> 3840 (0xf00)
                        [PLANE:37] 15 (CRTC_H) -> 2160 (0x870)
                        [PLANE:37] FORMAT: XRGB8888
                        [PLANE:30] 16 (FB_ID) -> 121 (0x79)
                        [PLANE:30] 19 (CRTC_ID) -> 47 (0x2f)
                        [PLANE:30] 8 (SRC_X) -> 0 (0x0)
                        [PLANE:30] 9 (SRC_Y) -> 0 (0x0)
                        [PLANE:30] 10 (SRC_W) -> 251658240 (0xf000000)
                        [PLANE:30] 11 (SRC_H) -> 141557760 (0x8700000)
                        [PLANE:30] 12 (CRTC_X) -> 0 (0x0)
                        [PLANE:30] 13 (CRTC_Y) -> 0 (0x0)
                        [PLANE:30] 14 (CRTC_W) -> 3840 (0xf00)
                        [PLANE:30] 15 (CRTC_H) -> 2160 (0x870)
                        [PLANE:30] FORMAT: ARGB8888

Do note, this is with e-DP as connector (it's previous gen xps 13'' laptop w/ i7-8550U).
Comment 3 emersion 2019-10-25 15:59:50 UTC 
After discussing with Pekka, agreed this is a userspace issue and ended up falling back to no modifiers when using modifiers fails: https://github.com/swaywm/wlroots/pull/1870

I guess Weston could come up with a similar solution.
Comment 4 Jani Saarinen 2019-10-25 16:01:23 UTC 
Thanks Simon.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.