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

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 :)

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.)

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.

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.

(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().

> 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.

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?

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

LIBGL_ALWAYS_SOFTWARE does not work still with weston, and the drm-backend. It USED to though

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.

Dang, doesn't work, even with GBM_ALWAYS_SOFTWARE

EGL_NOT_INITIALIZED...

Wait, I am wrong, I made a similar change in platform_wayland.c, not platform_drm.c
doing it in platform_drm.c worked

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.

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.

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.

-- 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.