Created attachment 142082 [details]
Error messages printed by weston when attempted to run from tty.
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 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.
Chris, how do you make this as missing dma-fence support?
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.
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.
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.
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.
I removed the misleading bit from the title, because lack of EGL_ANDROID_native_fence_sync will not stop weston.
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.
I was able to work around the problem using:
$ weston --use-pixmap
ugh. typo. $ weston --use-pixman
(can't edit comments?)
(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
(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.
(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?
(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.