Bug 108487 - Wayland compositors are unable to use hardware acceleration on i915
Summary: Wayland compositors are unable to use hardware acceleration on i915
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: 18.2
Hardware: Other Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-18 17:51 UTC by magiblot
Modified: 2019-05-16 14:14 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Error messages printed by weston when attempted to run from tty. (6.59 KB, text/plain)
2018-10-18 17:51 UTC, magiblot
Details
Stderr output of weston when successfully run on i965 (11.98 KB, text/plain)
2018-10-19 17:00 UTC, magiblot
Details
Stderr output of weston when successfully run on i965 (forcing the same OpenGL ES version than i915) (11.54 KB, text/plain)
2018-10-19 17:12 UTC, magiblot
Details
Stderr output of weston when run on i915 (with patch from comment #13) (9.08 KB, text/plain)
2019-01-31 18:25 UTC, magiblot
Details
gbm: gbm_bo_get_handle_for_plane fallback to nonplanar handle (649 bytes, patch)
2019-05-13 02:23 UTC, Alex Villacís Lasso
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description magiblot 2018-10-18 17:51:08 UTC
Created attachment 142082 [details]
Error messages printed by weston when attempted to run from tty.

Hello,

On my i915 system (Intel Atom N455 + Intel GMA 3150), Wayland compositors are unable to use hardware acceleration. I have tried KWin (KDE Plasma), Sway and weston.

Sway uses llvmpipe software rendering. Plasma 5 showed an error message similar to 'Could not initialize OpenGL' until version 5.13.0, when it began to fall back on software rendering as well. weston justs reveals the error messages 'failed to create gbm surface' / 'Failed to init output gl state' nowadays with its default configuration on Arch Linux x86_64.

Of course, there are no such issues on X11 sessions or when booting the same installation of linux in another computer that's not i915.

Here is some relevant output from glxinfo on X11:

> Extended renderer info (GLX_MESA_query_renderer):
>     Vendor: Intel Open Source Technology Center (0x8086)
>     Device: Mesa DRI Intel(R) Pineview M  (0xa011)
>     Version: 18.2.2
>     Accelerated: yes
>     Video memory: 384MB
>     Unified memory: yes
>     Preferred profile: compat (0x2)
>     Max core profile version: 0.0
>     Max compat profile version: 1.4
>     Max GLES1 profile version: 1.1
>     Max GLES[23] profile version: 2.0
> OpenGL vendor string: Intel Open Source Technology Center
> OpenGL renderer string: Mesa DRI Intel(R) Pineview M 
> OpenGL version string: 2.1 Mesa 18.2.2
> OpenGL shading language version string: 1.20
> OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.2.2
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

I'm also attaching the entire startup log from weston which contains the error messages I mentioned above.

I don't know if this is a bug or if it's a limitation of my hardware. In any case, I thought it best to report the issue here. Please ask me for any further information you need.

Thanks.
Comment 1 Daniel Stone 2018-10-19 13:56:09 UTC
Chris, how do you make this as missing dma-fence support?
Comment 2 Chris Wilson 2018-10-19 14:02:54 UTC
Just realised I missed the "timeline" part of

[17:35:45.463] warning: Disabling render GPU timeline due to missing EGL_ANDROID_native_fence_sync extension

(read as "disabling render GPU due to missing extension").

Since it doesn't say why it doesn't create the GL context, that looks like the easiest warning to fix first.
Comment 3 Daniel Stone 2018-10-19 14:10:08 UTC
The fatal bit is probably the GBM surface creation: my guess is that the KMS driver exposes IN_MODIFIERS so we try to use gbm_surface_create_with_modifiers and when it fails because i915 Mesa is blissfully unaware, we just tank the whole setup rather than falling back to no modifiers.
Comment 4 magiblot 2018-10-19 17:00:27 UTC
Created attachment 142102 [details]
Stderr output of weston when successfully run on i965

Here is the output weston-launch produces for me in a i965 device, with no errors, just so that you can compare it to the one from i915, since there are some warnings which are printed in both cases.
Comment 5 magiblot 2018-10-19 17:12:41 UTC
Created attachment 142104 [details]
Stderr output of weston when successfully run on i965 (forcing the same OpenGL ES version than i915)

I redid the log but forcing the use of OpenGL ES 2.0 on i965, the same version i915 uses, to make the differences more obvious.
Comment 6 Pekka Paalanen 2018-10-29 10:57:45 UTC
I removed the misleading bit from the title, because lack of EGL_ANDROID_native_fence_sync will not stop weston.
Comment 7 Duane Voth 2018-12-04 06:46:08 UTC
lspci on my laptop lists:
Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I get the same errors when trying to start weston:
...
[] failed to create gbm surface
[] Failed to init output gl state
[] Enabling output "LVDS-1" failed.
[] Error: cannot enable output 'LVDS-1' without heads.

From
https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg38763.html
I was able to work around the problem using:

$ weston --use-pixmap
Comment 8 Duane Voth 2018-12-04 06:59:07 UTC
ugh.  typo.   $ weston --use-pixman

(can't edit comments?)
Comment 9 magiblot 2018-12-04 11:13:00 UTC
(In reply to Duane Voth from comment #8)
> $ weston --use-pixman

Thanks for the hint. I hadn't tried this one.

The workaround dismisses the error message but, unfortunately, doesn't enable hardware acceleration, at least for me:

> $ glxinfo
>   Extended renderer info (GLX_MESA_query_renderer):
>      Vendor: VMware, Inc. (0xffffffff)
>      Device: llvmpipe (LLVM 7.0, 128 bits) (0xffffffff)
>      Version: 18.2.5
>      Accelerated: no
>      Video memory: 1982MB
>      Unified memory: no
Comment 10 Pekka Paalanen 2018-12-04 13:23:14 UTC
(In reply to magiblot from comment #9)
> The workaround dismisses the error message but, unfortunately, doesn't
> enable hardware acceleration

Yes, the whole point of --use-pixman is to use Pixman software rendering which will be faster than GL with a software renderer. If anything, it will disable hardware acceleration for the compositor and apps.

It is used to get something on screen, when hardware acceleration doesn't work for any reason.

Daniel's guess in comment #3 is still the best guess here.

One thing to test to confirm would be to hack Weston's build so that HAVE_GBM_MODIFIERS will not get defined. If that works, then we know that using gbm_surface_create_with_modifiers() does not work while gbm_surface_create() works.
Comment 11 magiblot 2018-12-05 19:47:49 UTC
(In reply to Pekka Paalanen from comment #10)

If all you need is a tester, I'm up for anything.

Is there any simple way (e.g. using a PKGBUILD file) to compile weston with undefined HAVE_GBM_MODIFIERS?

Thanks.
Comment 12 Pekka Paalanen 2018-12-10 08:36:18 UTC
(In reply to magiblot from comment #11)
> Is there any simple way (e.g. using a PKGBUILD file) to compile weston with
> undefined HAVE_GBM_MODIFIERS?

Not really, it needs to be patched out. There should be just one occurrence in configure.ac for it so hacking the condition to always evaluate to false or change the HAVE_ name to something else should do it.
Comment 13 Daniel Stone 2019-01-31 03:02:50 UTC
A Weston patch is available here, but needs testing: https://gitlab.freedesktop.org/wayland/weston/merge_requests/92
Comment 14 magiblot 2019-01-31 18:25:01 UTC
Created attachment 143267 [details]
Stderr output of weston when run on i915 (with patch from comment #13)

(In reply to Daniel Stone from comment #13)

Thank you very much! I applied the patch over weston-git and tried again. It got closer, but still doesn't work for me.

The following errors have now appeared:

> [13:53:34.450] failed to create kms fb: No such file or directory
> [13:53:34.450] failed to get drm_fb for bo
> [13:53:34.979] failed to create kms fb: No such file or directory
> [13:53:34.980] failed to get drm_fb for bo
> [13:53:35.035] failed to create kms fb: No such file or directory
> [13:53:35.035] failed to get drm_fb for bo

weston doesn't crash or anything. After startup, the content of the tty continues being shown and weston appears to be idle. Ctrl+Alt+Backspace exits weston normally and control is given back to the shell.

Cheers.
Comment 15 Number Nine 2019-03-09 14:18:53 UTC
I have the same exact problem on HP Pavilion DV4000 and I do confirm that undefining HAVE_GBM_MODIFIERS (5c8eef147c27a95ebb8ba79e19ebb190b025cbe0) allows Weston to run without --use-pixman.
Comment 16 Number Nine 2019-03-09 14:21:19 UTC
(In reply to magiblot from comment #14)
> Created attachment 143267 [details]
> Stderr output of weston when run on i915 (with patch from comment #13)
> 
> (In reply to Daniel Stone from comment #13)
> 
> Thank you very much! I applied the patch over weston-git and tried again. It
> got closer, but still doesn't work for me.
> 
> The following errors have now appeared:
> 
> > [13:53:34.450] failed to create kms fb: No such file or directory
> > [13:53:34.450] failed to get drm_fb for bo
> > [13:53:34.979] failed to create kms fb: No such file or directory
> > [13:53:34.980] failed to get drm_fb for bo
> > [13:53:35.035] failed to create kms fb: No such file or directory
> > [13:53:35.035] failed to get drm_fb for bo
> 
> weston doesn't crash or anything. After startup, the content of the tty
> continues being shown and weston appears to be idle. Ctrl+Alt+Backspace
> exits weston normally and control is given back to the shell.
> 
> Cheers.

If you add #undef HAVE_GBM_MODIFIERS into libweston/compositor-drm.c and rebuild, it should do as a temporary hack.
Comment 17 Alex Villacís Lasso 2019-04-27 23:33:53 UTC
I see the exact same issue on my machine when trying weston. This bug is very similar to one I had a hand in working around in mutter: https://gitlab.gnome.org/GNOME/mutter/issues/127 . The mutter workaround essentially tries calling gbm_bo_get_handle_for_plane() on plane 0 of the bo, sees if the call succeeded, and if not, falls back on calling gbm_bo_get_handle() while storing DRM_FORMAT_MOD_INVALID, which in turn causes the subsequent code to call drmModeAddFB[2]() instead of the unsupported drmModeAddFB2WithModifiers().

This should really be fixed in mesa. Quoting myself from the mutter bug report:
----- BEGIN QUOTE -----
@daniels I think I found the cause why mesa code fails the gbm_bo_get_handle_for_plane call with the i915 driver. However, it is not clear to me whether it is an actual bug, or just the code "working" as designed.

The gbm_bo_get_handle_for_plane implementation was introduced by commit f9567ab435217a72cbae628336ead84dc0b2a803 (gbm: Export a getter for per plane handles). This implementation contains the following check, which remains to this day:

   if (!dri->image || dri->image->base.version < 13 || !dri->image->fromPlanar)
   {
      errno = ENOSYS;
      return ret;
   }

One of the conditions for the call is that the base.version member is 13 or above. This member (dri->image) is a __DRIimageExtension *, according to src/gbm/backends/dri/gbm_driint.h in the Mesa code.

There are several DRI drivers that define a static __DRIimageExtension with type __DRI_IMAGE, along with an API version. In the case of i965 (src/mesa/drivers/dri/i965/intel_screen.c), the api is at version 16. However, in the case of i915 (src/mesa/drivers/dri/i915/intel_screen.c) the api is at version 7.

At first sight, it looks as though the version check in the initial commit is too restrictive. According to include/GL/internal/dri_interface.h in the Mesa code, the fromPlanar member of __DRIimage should be available since __DRI_IMAGE API version 5. However, the commit does not include comments on why version 13 is the minimum required for fetching the plane handle. Again, according to include/GL/internal/dri_interface.h, the one property that requires 13 as a minimum is __DRI_IMAGE_ATTRIB_OFFSET. So maybe the code assumes that whoever calls  gbm_bo_get_handle_for_plane will also fetch the offset.

----- END QUOTE -----
Comment 18 Alex Villacís Lasso 2019-05-13 02:23:27 UTC
Created attachment 144243 [details] [review]
gbm: gbm_bo_get_handle_for_plane fallback to nonplanar handle

Here is a patch for Mesa 19.0.3 that fixes the issue for me on Fedora 30 x86_64. Essentially the patch returns the nonplanar handle if the API check fails, making the gbm_bo_get_handle_for_plane() call equivalent to gbm_bo_get_handle() if requesting plane 0. With this patch, weston starts up and works correctly for me. Gnome Shell remains unaffected.

Merge request (against master) here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/871

This should eventually be backported to 19.0.
Comment 19 Daniel Stone 2019-05-16 14:14:09 UTC
Fixed with b2200514 in Mesa.


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.