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.
A Weston patch is available here, but needs testing: https://gitlab.freedesktop.org/wayland/weston/merge_requests/92
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.
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.
(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.
If you add #undef HAVE_GBM_MODIFIERS into libweston/compositor-drm.c and rebuild, it should do as a temporary hack.
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() 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;
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 -----
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.
Fixed with b2200514 in Mesa.