Bug 108487 - Wayland compositors are unable to use hardware acceleration on i915
Summary: Wayland compositors are unable to use hardware acceleration on i915
Status: NEW
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: 2018-12-10 08:36 UTC (History)
2 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

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.


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.