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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 6 13:32:27 UTC 2019


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 at lists.freedesktop.org
          Reporter: jwrdegoede at fedoraproject.org
        QA Contact: mesa-dev at 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:

--- 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;

Which works, but meh.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190806/31355480/attachment.html>


More information about the mesa-dev mailing list