|Summary:||[KBL] Black screen with I915_FORMAT_MOD_Y_TILED_CCS (Requested display configuration exceeds system DDB limitations)|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||RESOLVED NOTOURBUG||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Priority:||not set||CC:||intel-gfx-bugs, kenny.macdermid|
|i915 platform:||KBL||i915 features:|
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  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 . 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? : https://github.com/swaywm/wlroots/issues/1852 : 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