Bug 109258 - Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
Summary: Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-09 11:42 UTC by n3rdopolis
Modified: 2019-09-18 18:07 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Reverse 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 (2.72 KB, patch)
2019-01-18 03:19 UTC, n3rdopolis
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description n3rdopolis 2019-01-09 11:42:50 UTC
Hi

I first noticed this on UDL/Displaylink, but now I see this on QXL too
Weston's gl-backend fails to initialize EGL, 0x3001 , and quits. 

I noticed it selects a (null) driver. I am not sure how long this issue has been happening, it's not an immediate regression that I noticed, but I know it used to work a few years ago IIRC. I tried to include everything relevant...

I reported this to the Wayland project as well, but it appears that they suggested to report it here https://gitlab.freedesktop.org/wayland/weston/issues/183

I tried different GALLIUM_DRIVERs as well

relevant variables:
COGL_RENDERER=egl_wayland
LIBGL_ALWAYS_SOFTWARE=1


Weston log output:
Date: 2019-01-09 UTC
[03:45:43.647] weston 5.0.90
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 5.0.0-110-g13dda10f+
[03:45:43.649] Command line: weston
[03:45:43.650] OS: Linux, 4.19.0-1-686-pae, #1 SMP Debian 4.19.12-1 (2018-12-22), i686
[03:45:43.652] Using config file '/home/beccaholic/.config/weston.ini'
[03:45:43.653] Output repaint window is 7 ms maximum.
[03:45:43.654] Loading module '/opt/lib/i386-linux-gnu/libweston-5/drm-backend.so'
[03:45:43.660] initializing drm backend
[03:45:43.671] logind: session control granted
[03:45:43.676] using /dev/dri/card0
[03:45:43.678] DRM: supports universal planes
[03:45:43.678] DRM: does not support atomic modesetting
[03:45:43.679] DRM: supports picture aspect ratio
[03:45:43.680] Loading module '/opt/lib/i386-linux-gnu/libweston-5/gl-renderer.so'
pci id for fd 14: 1234:1111, driver (null)
[03:45:43.717] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_device_base EGL_EXT_device_enumeration
               EGL_EXT_device_query EGL_EXT_platform_base
               EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
               EGL_EXT_platform_wayland EGL_EXT_platform_x11
               EGL_MESA_platform_gbm
[03:45:43.718] failed to initialize display
[03:45:43.718] EGL error state: EGL_NOT_INITIALIZED (0x3001)
[03:45:43.719] failed to initialize egl
[03:45:43.720] fatal: failed to create compositor backend
[03:45:43.720] Internal warning: debug scope 'drm-backend' has not been destroyed.

This is what I compiled Mesa with
meson --buildtype=plain --prefix=$INSTALLDIR --libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) -Dgles1=true -Dgles2=true -Dplatforms=x11,wayland,drm -Dgallium-drivers=nouveau,svga,r300,r600,swrast,radeonsi,virgl -Ddri-drivers=r200,nouveau,i915,i965 -Dosmesa=gallium -Dgallium-xa=true -Dgbm=true -Dshared-glapi=true -Dshared-llvm=true -Dvulkan-drivers=intel,amd -Dllvm=true build 

Could I possibly be missing an option?
Comment 1 n3rdopolis 2019-01-15 05:20:01 UTC
Hi 

I tested on an older image of a system that I have. (testing a few)
Then testing different Mesa revisons.

I have narrowed this down to commit 8cb84c8477a57ed05d703669fee1770f31b76ae6 
"egl: move alloc & init out of _eglBuiltInDriver{DRI2,Haiku}" on 	2017-10-18

as the commit 4893673b155b9ff2e0fc0730b214ba3bcbe75a89 before it works.
I am able to run weston with LIBGL_ALWAYS_SOFTWARE with a mesa built from this commit




Thanks
Comment 2 Eric Engestrom 2019-01-15 18:34:20 UTC
I can reproduce, I'll take a look. Thanks for the report :)

As for your bisect, I had messed up a rebase and accidentally dropped a line in 8cb84c8477a57ed05d70, which lead to Marek reverting my commit a few weeks later in 84f3afc2e122cb418573. About a year later, I remembered about all this and fixed up the issue, and the commit landed as cb0980e69aa921af7086.

This might help you bisect, as you now know that all the commit between 8cb84c8477a57ed05d70 and 84f3afc2e122cb418573 are broken :)
Comment 3 n3rdopolis 2019-01-16 04:21:05 UTC
Haha. after all that manual bisecting too :) However, I feel something was still broken, because I found a built Mesa I had from a January 2018 commit in master, that didn't work...


To verify, I tried to see if the 84f3afc2e122cb418573f1e9c61716520f9859c1 commit would work, and it actually did not.

It seems another commit caused another problem I guess. Thankfully there weren't too many EGL commits between this, so I narrowed it down to two. I first tried to revert commit 47273d7312cb5b5b6b0b9faa814d574bbbce1c01
and then trying again, and Weston ran! 

I quickly skimmed the webgit log this time, and now I don't think I saw any mentions of 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 being reverted this time.


(My second guess would have d7e769abec732fd23b93145a519065c82b2ccb2b . Thankfully it wasn't, as that one conflicted during the revert.)
Comment 4 Daniel van Vugt 2019-01-17 04:57:08 UTC
mutter has the same issue with LIBGL_ALWAYS_SOFTWARE=1 in Ubuntu 19.04 right now. It just fails to start in a similar way.

mutter version 3.30.2-4 says:

(mutter:14910): mutter-WARNING **: 12:53:43.586: Failed to create backend: Failed to initialize renderer: EGL is not initialized, or could not be initialized, for the specified EGL display connection., Missing EGL extensions required for EGLDevice renderer: EGL_EXT_device_base

mutter master says:

(mutter:14901): mutter-WARNING **: 12:53:10.264: Failed to create backend: Failed to initialize renderer: EGL is not initialized, or could not be initialized, for the specified EGL display connection.

Mesa is version 18.2.8-2ubuntu1. Sorry I don't have time to bisect Mesa at the moment.
Comment 5 n3rdopolis 2019-01-18 03:19:35 UTC
Created attachment 143147 [details] [review]
Reverse 47273d7312cb5b5b6b0b9faa814d574bbbce1c01

Weston and Gnome shell work with LIBGL_ALWAYS_SOFTWARE with this patch, but all I did was revert commit 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 and then changed up the conflicts.
Comment 6 Eric Engestrom 2019-01-22 10:37:18 UTC
(In reply to n3rdopolis from comment #5)
> Created attachment 143147 [details] [review] [review]
> Reverse 47273d7312cb5b5b6b0b9faa814d574bbbce1c01
> 
> Weston and Gnome shell work with LIBGL_ALWAYS_SOFTWARE with this patch, but
> all I did was revert commit 47273d7312cb5b5b6b0b9faa814d574bbbce1c01 and
> then changed up the conflicts.

This revert makes Mesa ignore LIBGL_ALWAYS_SOFTWARE for the drm (and android) platforms.
This is making it "work" by not doing what the user asked for, which is not what we want.

DRM does not have a software path yet, hence the
    /* Not supported yet */
    if (disp->Options.ForceSoftware)
       return EGL_FALSE;
in dri2_initialize_drm()

If a software DRM path is needed, then patches to implement it are welcome :)
I have to admit for rendering I'm not sure what needs to be done there, but for display if you don't have a DRM driver you can use VKMS.

I'm closing this as NOTABUG, as EGL is working as intended.

If a wayland compositor want to discard the user's instructions and use the hardware when given LIBGL_ALWAYS_SOFTWARE, it needs to override the env var (set to `0` or simply unset) before calling eglInitialize().
Comment 7 Daniel van Vugt 2019-01-23 02:17:42 UTC
> This revert makes Mesa ignore LIBGL_ALWAYS_SOFTWARE for the drm (and android) platforms.

That might be what it looks like, but as I understand it the opposite is true...

The bug being fixed here is that Mesa is already ignoring LIBGL_ALWAYS_SOFTWARE right now. I recall it used to work a few years ago, but at present LIBGL_ALWAYS_SOFTWARE is being ignored.

I'm not saying that 'Options.ForceSoftware' was how it used to work, I don't know. But for certain LIBGL_ALWAYS_SOFTWARE=1 did used to work on DRM because I used to use it in Mir server development.
Comment 8 Pekka Paalanen 2019-01-29 08:35:20 UTC
Eric, are you sure software render was never implemented?

I am pretty sure that if you bring up EGL GBM platform and you miss a hardware driver, it will use llvmpipe and it will get stuff on screen (even if it has synchronization issues). I have had to patch Mutter to explicitly check for llvmpipe et al. and stop using EGL GBM in that case in favor of another path that does not suffer from the synchronization issues.

Is there a significant difference between the automatic fallback to llvmpipe and using LIBGL_ALWAYS_SOFTWARE? Maybe one should use EGL_SOFTWARE=1 or such, does that still exist?
Comment 9 n3rdopolis 2019-02-01 03:28:56 UTC
IIRC, EGL_SOFTWARE=1  stopped working a while ago, sometime in 2015 it appears LIBGL_ALWAYS_SOFTWARE was what was working since then, until this change
Comment 10 n3rdopolis 2019-06-28 00:53:31 UTC
LIBGL_ALWAYS_SOFTWARE does not work still with weston, and the drm-backend. It USED to though
Comment 11 Brendan King 2019-06-28 09:15:38 UTC
I'm pretty sure I've got this to work, by removing the following block of code from function dri2_initialize_drm in platform_drm.c:

   /* Not supported yet */
   if (disp->Options.ForceSoftware)
      return EGL_FALSE;

and setting both GBM_ALWAYS_SOFTWARE=1 and LIBGL_ALWAYS_SOFTWARE=1 when running Weston. IIRC, the first variable is needed for the compositor to use software rendering, and the second for the other Weston processes.
Comment 12 n3rdopolis 2019-06-28 22:37:45 UTC
Dang, doesn't work, even with GBM_ALWAYS_SOFTWARE

EGL_NOT_INITIALIZED...
Comment 13 n3rdopolis 2019-06-29 16:36:38 UTC
Wait, I am wrong, I made a similar change in platform_wayland.c, not platform_drm.c
doing it in platform_drm.c worked
Comment 14 Brendan King 2019-07-01 14:25:32 UTC
That block of code in platform_drm.c appears to be incorrect. The ForceSoftware flag is derived from the LIBGL_ALWAYS_SOFTWARE environment variable, but platform_drm uses GBM, with the DRM backend, which uses the GBM_ALWAYS_SOFTWARE environment variable to force software rendering, not LIBGL_ALWAYS_SOFTWARE. In any case, software rendering does appear to be supported, despite what the comment says.
Comment 15 Emil Velikov 2019-07-01 16:16:14 UTC
Let's reopen this. Can someone provide a simple how-to, for example:

HW X, weston/wayland server vY
env.variables A, B, C - before and after launching wayland server

Chances are we end up going through some strange mix of swrast and kms_swrast.


Note: Usually the Wayland server itself uses platform_drm, while apps within the Wayland server platform_wayland.
Comment 16 Brendan King 2019-07-02 08:54:58 UTC
I've been able to run Weston with the software rasteriser, using the recipe given in comment 11 (including the code removal), since Mesa 18.1.0, and Weston 4.0. I've only tried this with the Gallium "swrast" software rasteriser (kms_swrast), which gets installed as both kms_swrast_dri.so, and swrast_dri.so. No other software rasteriser is enabled in the Mesa build.
Comment 17 GitLab Migration User 2019-09-18 18:07:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/165.


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.