We fall back to using GLX in glxtest when available because there's no EGL_MESA_query_renderer extension yet, which again provides infos we use to e.g. whitelist devices for Webrender. This is unfortunate for several reasons:

• On Wayland it requires an xserver to run and be reachable. This is bad for Wayland only environments, in a flatpak sandboxes with X11_fallback set for better security or if the xserver is started on demand, like Gnome will do in the future
• On X11 it blocks us from deprecating / disabling GLX

This is blocked by the corresponding feature request for mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976

This also includes:

• prefere GL on EGL and use GLES only as fallback
• some cleanups

Btw., I of course meant there's no EGL_MESA_query_renderer extension yet :)

Eric posted some patches that could satisfy our needs here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976#note_557557

As I'm just a user I can't assess the following, but wanted to mention it:

https://searchfox.org/mozilla-central/rev/31d8600b73dc85b4cdbabf45ac3f1a9c11700d8e/widget/GfxInfoX11.cpp#270
Currently, Firefox wants to detect whether it runs with hardware or software OpenGL:
First it checks glRenderer string for "llvmpipe", "softpipe" and "software rasterizer", then it relies on MESA_ACCELERATED.

I assume the following:

• If hardware OpenGL is available, it should be used for WebRender and WebGL.
• If only software OpenGL is available, it should only be used for WebGL. Basic layers (Skia software rendering) should be used instead of WebRender.
  (Software WebRender (bug 1601053) will replace Basic layers in the future. It has its own minimal software GL implementation: bug 1612941 comment 28. I assume llvmpipe should still be used for WebGL then?)

On EGL, Firefox should still be able to detect whether it has to use WebRender or software rendering.

These two seem to be reponsible for GLX_RENDERER_ACCELERATED_MESA (MESA_ACCELERATED):
https://github.com/mesa3d/mesa/search?q=__DRI2_RENDERER_ACCELERATED
https://github.com/mesa3d/mesa/search?q=PIPE_CAP_ACCELERATED

Is it enough to have a hardcoded list and to compare the glRenderer string? What is desired?

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #4)

As I'm just a user I can't assess the following ...

You are funny :)

First it checks glRenderer string for "llvmpipe", "softpipe" and "software rasterizer", then it relies on MESA_ACCELERATED.
...
Is it enough to have a hardcoded list and to compare the glRenderer string? What is desired?

Ah somehow missed that...Eric, would it be much work to expose something like EGL_RENDERER_ACCELERATED_MESA as well?

If the device query way of doing this works for you guys, making another extension to provide eglQueryDeviceAttribEXT(EGL_QUERY_RENDERER_ACCELERATED_EXT) (or something like that) should be trivial.

I just had a closer look, and in Mesa the presence of EGL_EXT_output_drm in a given device's extension string is enough to determine if the device is hardware-backed or not.

DRM (and therefore this extension) is not cross-platform, so you won't see it on Windows, but on Linux & *BSD it's a reliable check, and has been available in Mesa since 18.3.0 2 years ago, and in NVIDIA's closed driver since 364.12 4 years ago.

Reminder to myself: looks like this could also improve the situation with dGPUs, see https://www.omgubuntu.co.uk/2020/07/firefox-enable-webrender-linux#comment-5008436454 (errors because of "no visuals found", something we can skip for EGL as we don't need to create a window).

(In reply to Eric Engestrom from comment #7)

I just had a closer look, and in Mesa the presence of EGL_EXT_output_drm in a given device's extension string is enough to determine if the device is hardware-backed or not.

DRM (and therefore this extension) is not cross-platform, so you won't see it on Windows, but on Linux & *BSD it's a reliable check, and has been available in Mesa since 18.3.0 2 years ago, and in NVIDIA's closed driver since 364.12 4 years ago.

Thanks Eric, that seems to work indeed.

FTR: this turned out to be a much bigger rewrite than initially thought. As I'm on it, I want to make sure that e.g. the Wayland backend is on par with the X11 one, requiring to change e.g. screen resolution detection - which should be shared between X11 GLX and EGL, but not Wayland etc. But it's mostly done now.

This does quite a bunch at once, including:

1. On Wayland, use get_egl_status() by default
2. Implement get_wayland_screen_info() by copying from weston-info.

• this avoids opening a X11 connection
• we now get the actual number of screens. Previously, we'd fall back
  to using the info from Xwayland, which always reports one single big
  screen with the combined size (e.g. 3840x1080 instead of 2x1920x1080)
• monitor scale is recorded but not used yet

3. On X11/EGL use x11_egltest(), avoiding runtime dependencies on GLX
4. Avoid dlopening libgl/libgles on EGL if not needed
5. More Wayland/X11 ifdef cleanups

Implement get_wayland_screen_info() by copying from weston-info.
This allows us to get the actual number of screens. Previously, we'd
fall back to using the info from Xwayland, which always reports one
single big screen with the combined size (e.g. 3840x1080 instead of
2x1920x1080). Also, this avoids opening a X11 connection.

Note:

• monitor scale is recorded but not used yet
• the code could be simplified. However, keeping the weston-info
  structure would allow us to easily add queries for other extensions
  in the future if desired.

https://hg.mozilla.org/mozilla-central/rev/1e4694531f83
https://hg.mozilla.org/mozilla-central/rev/ad82c5c9ba14

https://hg.mozilla.org/mozilla-central/rev/1e4694531f83
https://hg.mozilla.org/mozilla-central/rev/ad82c5c9ba14

https://hg.mozilla.org/mozilla-central/rev/572aab2df711

This indeed makes us mostly stop opening X11 connections on the Wayland backend \o/

Gnome is about to land Xwayland-on-demand[1] and since these patches landed, FF does not trigger a start any more. Unfortunately, WebRTC for some reason still appears to connect to the X server - however, this is somewhat expected, judging from the efforts to build FF without X11 support.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673

As a consequence of this change, I noticed that about:support shows "0" as video RAM with MOZ_X11_EGL=1 or MOZ_ENABLE_WAYLAND=1, whereas it shows "1024" with GLX. Should this be fixed in Firefox (at the moment?) or does Mesa need an additional feature so that about:support can show a more sensible value?

(In reply to Viktor Jägersküpper from comment #19)

As a consequence of this change, I noticed that about:support shows "0" as video RAM with MOZ_X11_EGL=1 or MOZ_ENABLE_WAYLAND=1, whereas it shows "1024" with GLX. Should this be fixed in Firefox (at the moment?) or does Mesa need an additional feature so that about:support can show a more sensible value?

Yeah, you got me :P

This is the one feature that currently can't be realized with EGL on mesa until someone steps up to continue with https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976. I figured it's not important enough to fall back to GLX for it, especially as the GLX counterpart is not properly/meaningful implemented either (see https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976#note_588793).

However, apparently it's possible via libpci (https://www.cyberciti.biz/faq/howto-find-linux-vga-video-card-ram/) - as we use that already, we could probably extend it to also report memory.

(In reply to Robert Mader [:rmader] from comment #20)

This is the one feature that currently can't be realized with EGL on mesa until someone steps up to continue with https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976. I figured it's not important enough to fall back to GLX for it, especially as the GLX counterpart is not properly/meaningful implemented either (see https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976#note_588793).

I looked at this, although unfortunately I don't understand the details. I didn't file a bug because I wondered if the amount of physical/available video RAM is useful at all here. So I am fine with the current situation.