[Bug,111306] gbm creates BO with wrong pitch when dri3_get_modifiers returns modifiers, causing drmModeAddFB2WithModifiers to fail

Submitted by bugzilla-daemon@freedesktop.org on Aug. 6, 2019, 1:32 p.m.

Details

Message ID bug-111306-598@http.bugs.freedesktop.org/
State New
Headers show
Series "gbm creates BO with wrong pitch when dri3_get_modifiers returns modifiers, causing drmModeAddFB2WithModifiers to fail" ( rev: 1 ) in Mesa

Not browsing as part of any series.

Commit Message

bugzilla-daemon@freedesktop.org Aug. 6, 2019, 1:32 p.m.
https://bugs.freedesktop.org/show_bug.cgi?id=111306

            Bug ID: 111306
           Summary: gbm creates BO with wrong pitch when
                    dri3_get_modifiers returns modifiers, causing
                    drmModeAddFB2WithModifiers to fail
           Product: Mesa
           Version: 19.1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
          Assignee: mesa-dev@lists.freedesktop.org
          Reporter: jwrdegoede@fedoraproject.org
        QA Contact: mesa-dev@lists.freedesktop.org

This was first discussed here:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/254

Where I came up with a completely wrong fix.

The easiest way to reproduce this is:

1) Take a Skylake iGPU (in my case with 2 1920x1080 monitors attached)
2) Run Xorg master with the modesetting driver (master is necessary because
glamor has support for modifiers enabled only in master)
3) Run a recent gnome-shell on top of Xorg
4) Run xrandr --fb <width>x<height> changing the width to be 32 pixels larger
then necessary (or any other value not a multiple of 64)
5) Watch Xorg.log filling with errors like these:

[ 28843.414] (WW) modeset(0): Page flip failed: Invalid argument
[ 28843.414] (EE) modeset(0): present flip failed
[ 28843.595] (WW) modeset(0): Page flip failed: Invalid argument
[ 28843.595] (EE) modeset(0): present flip failed

https://gitlab.freedesktop.org/xorg/xserver/merge_requests/254 has a completely
wrong workaround for this by disabling modifier support when a secondary GPU
with outputs is present, but that just happen to cause a fb width which was not
a multiple of 64.

As mentioned above the problem can be reproduced on a single GPU. The problem
seems to be that when the xserver's dri3_get_modifiers method returns a
non-empty modifier list, gbm creates buffer-objects using these modifiers
(fine) without taking the pitch requirements into account. Or at least without
taking the pitch requirements for using these modifiers on a BO which is to be
used as a framebuffer into account. This causes the Present extension flip done
with a pixmap backed by this BO to fail (the xserver will fallback to a bitblt
in this case).

Fixing this may require new API, since currently when using modifiers it is not
possible to indicate that the BO will be used for scanout AFAICT.

Another Xserver level workaround is this:


Which works, but meh.

Patch hide | download patch | download mbox

--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -693,6 +693,12 @@  xf86RandR12ScreenSetSize(ScreenPtr pScreen,
     if (pRoot && pScrn->vtSema)
         (*pScrn->EnableDisableFBAccess) (pScrn, FALSE);

+    /*
+     * Present flipping with modifiers may fail if our screen width is not
+     * a multiple of 64.
+     */
+    width = (width + 63) & ~63;
+
     /* Let the driver update virtualX and virtualY */
     if (!(*config->funcs->resize) (pScrn, width, height))
         goto finish;

Comments