788319 - (linux-egl) [meta] Use EGL instead of GLX on X11

Status: NEW

(Core :: Graphics: WebRender, enhancement)

Description

[Marco Castelluccio [:marco]]

From http://www.phoronix.com/scan.php?page=news_item&px=MTE3MTI:

---
Also mentioned by Eric is "GLX is pretty much deprecated at this point." Intel is encouraging developers to use EGL rather than GLX. EGL is needed anyways for Wayland, Android, OS X, etc and the Mesa EGL support has matured quite well and still works fine with an X.Org Server. Eric said, "Please please please stop using GLX. There shouldn't be anything left that GLX has that EGL doesn't."
---

Comment 1

[Karl Tomlinson (:karlt)]

One useful piece of information here would be which version of Mesa has sufficiently "mature" EGL support.  Currently we require Mesa 7.10.3 (but 8.0 with nouveau).

Comment 2

[Benoit Jacob [:bjacob] (mostly away)]

This would also be an instant win for WebGL, as it runs better (faster, using less memory) on top of GLES than desktop GL.

Comment 3

[Marco Castelluccio [:marco]]

http://www.phoronix.com/scan.php?page=news_item&px=MTE5MTU

Comment 4

[Ian Romanick]

For Intel Sandybridge and Ivybridge GPUs, we submitted OpenGL ES 2.0 conformance test results on Mesa 8.0.4.  I believe that the tests ran well on 7.11.something on Sandybridge, but we never submitted those results.  I assume Firefox doesn't do anything exotic with EGL, so it should be fine.  Most of the important infrastructure is shared with GLX.

Comment 5

[Karl Tomlinson (:karlt)]

Sounds like we definitely want to move to EGL for the new OpenGL library ABI if/when that happens.

The NVIDIA GeForce driver might be the last thing holding us back before then.

Comment 6

[Kelsey Gilbert [:jgilbert]]

Moving to EGL opens up the ability to use EGLImage to share textures instead of using context sharing, which has the potential to improve performance slightly.

Comment 7

[Kelsey Gilbert [:jgilbert]]

Well, I should say, we could use EGLImage where available. I don't know if Mesa supports or has any plan to support it, but it would be nice to have.

Comment 8

[Ian Romanick]

Mesa already supports it, and, I believe, Wayland uses it.  You may encounter issues, and we look forward to your bug reports. :)

Comment 9

[George Wright (:gw280) (needinfo me!)]

This would also be of great important to Raspberry Pi, as their drivers only support EGL and not GLX on X11.

Comment 10

[Nick Cameron [:nrc]]

Attachment: initial wip

Comment 11

[Nick Cameron [:nrc]]

I've had a go at looking into this the last couple of evenings, I didn't get very far. With the patch, you can add the following to your mozconfig:

ac_add_options --with-gl-provider=EGL
ac_add_options --enable-default-toolkit=cairo-gtk2-egl

(actually, you probably only need the second line) and Firefox will build and run without crashing. (I also had to build my own version of Mesa, but not sure if there might have been an easier way). But all we get rendered is a black screen - no warnings, no assertions.

I had assumed we'd need to do some work to get gtk and egl to play nice, but I was kind of hoping I would get some hints rather than just a black screen.

Anyone got any ideas?

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Suggestion: run a debug build with MOZ_GL_DEBUG_ABORT_ON_ERROR=1 to see if you get GL errors, or use APItrace.

Comment 13

[Nick Cameron [:nrc]]

(In reply to Benoit Jacob [:bjacob] from comment #12)
> Suggestion: run a debug build with MOZ_GL_DEBUG_ABORT_ON_ERROR=1 to see if
> you get GL errors, or use APItrace.

So this gave me nothing.

I also tried disabling xrender, but that did nothing too.

AND THEN, for reasons I completely and utterly fail to understand, it spontaneously started working on me. As far as I can tell it is using EGL and doing all it should do without any errors. Which, I'm suspicious. I'll do some more testing. (btw I re-enabled xrender and turned off GL_DEBUG and it still worked, then I rebooted and it still worked).

Comment 14

[Nick Cameron [:nrc]]

A little more testing and it mostly works. OMTC is totally borked - just a big black screen, but main thread is OK. WebGL doesn't seem to work. And when using an intermediate surface for container layers, it renders OK, but I get some kind of GL abort when using MOZ_GL_DEBUG_ABORT_ON_ERROR. So, a few things to fix up, but at least it is not a mysterious blank screen.

Comment 15

[Nick Cameron [:nrc]]

Turns out the intermediate surface thing is nothing to do with EGL. It is fixed in bug 863968.

Comment 16

[Nick Cameron [:nrc]]

I got webgl working, but only with readback. I'll look at OMTC next, but not tonight. Patches coming soon-ish.

jgilbert - I seem to be having problems with streaming buffers stuff, but this stuff must work on Android right? Does anything come to mind where there are assumptions that EGL => Android or OMTC? Sorry this is a bit vague, when I get some more time, I'll figure out a real question :-p

Comment 17

[Benoit Jacob [:bjacob] (mostly away)]

You may want to take a quick look at bug 863397. In particular, I'm removing the eglLockSurface-based optimizations there because they belong in dedicated TextureClient/TextureHosts rather than in GLContextProviderEGL.cpp. I don't know if eglLockSurface is available in Mesa.

Comment 18

[Oleg Romashin (:romaxa)]

Comment on attachment 738390 [details] [diff] [review]
initial wip


>     mNeedsYFlip = false;
>-#if defined(MOZ_X11) && !defined(MOZ_PLATFORM_MAEMO)
>+#if defined(GL_PROVIDER_GLX) && !defined(MOZ_PLATFORM_MAEMO)
>     if (aData.mSurface->GetType() == gfxASurface::SurfaceTypeXlib) {
>         gfxXlibSurface *xsurf = static_cast<gfxXlibSurface*>(aData.mSurface);

keep it as just 
+#if defined(GL_PROVIDER_GLX)

Comment 19

[Nick Cameron [:nrc]]

Working for OMTC too! Turns out we should not tell CompositorParent we are using EGL unless we are on Android and therefore intend to send surface size info.

Comment 20

[Nick Cameron [:nrc]]

(In reply to Benoit Jacob [:bjacob] from comment #17)
> You may want to take a quick look at bug 863397. In particular, I'm removing
> the eglLockSurface-based optimizations there because they belong in
> dedicated TextureClient/TextureHosts rather than in
> GLContextProviderEGL.cpp. I don't know if eglLockSurface is available in
> Mesa.

Thanks for the heads up! I think we can get something working without any of that. I guess if we want to pursue using EGL more in the future we can put it back in as a texture client/host.

Comment 21

[Nick Cameron [:nrc]]

Attachment: basic fixups

This version just requires |ac_add_options --with-gl-provider=EGL| in your mozconfig.

Comment 22

[Nick Cameron [:nrc]]

Attachment: WIP webgl

WIP, in case anyone wants to test this stuff. Just using forced readback for now.

Comment 23

[Nick Cameron [:nrc]]

Attachment: WIP webgl

Comment 24

[Kelsey Gilbert [:jgilbert]]

(In reply to Nick Cameron [:nrc] from comment #19)
> Working for OMTC too! Turns out we should not tell CompositorParent we are
> using EGL unless we are on Android and therefore intend to send surface size
> info.

Sounds like we should fix that. None of the streaming stuff should assume that EGL is android.

Comment 25

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 740058 [details] [diff] [review]
basic fixups

Review of attachment 740058 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/xpwidgets/nsBaseWidget.cpp
@@ +876,5 @@
>                                                      int aSurfaceHeight)
>  {
> +  // Even if we are using EGL, unless we are on Android, we don't want
> +  // CompositorParent to think we are, so we pass aRenderToEGLSurface = false.
> +  return new CompositorParent(this, false, aSurfaceWidth, aSurfaceHeight);

I would like to know how hard this is to fix, since this just screams 'hack'.

Comment 26

[Nick Cameron [:nrc]]

(In reply to Jeff Gilbert [:jgilbert] from comment #25)
> Comment on attachment 740058 [details] [diff] [review]
> basic fixups
> 
> Review of attachment 740058 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: widget/xpwidgets/nsBaseWidget.cpp
> @@ +876,5 @@
> >                                                      int aSurfaceHeight)
> >  {
> > +  // Even if we are using EGL, unless we are on Android, we don't want
> > +  // CompositorParent to think we are, so we pass aRenderToEGLSurface = false.
> > +  return new CompositorParent(this, false, aSurfaceWidth, aSurfaceHeight);
> 
> I would like to know how hard this is to fix, since this just screams 'hack'.

Well, I think it is just that aRenderToEGLSurface really means aExternallyProvidedSurfaceSize or something, so the fix is just to rename the argument and corresponding member. I don't think that this flag is used for anything actually related to EGL.

Comment 27

[Kelsey Gilbert [:jgilbert]]

(In reply to Nick Cameron [:nrc] from comment #26)
> (In reply to Jeff Gilbert [:jgilbert] from comment #25)
> > Comment on attachment 740058 [details] [diff] [review]
> > basic fixups
> > 
> > Review of attachment 740058 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: widget/xpwidgets/nsBaseWidget.cpp
> > @@ +876,5 @@
> > >                                                      int aSurfaceHeight)
> > >  {
> > > +  // Even if we are using EGL, unless we are on Android, we don't want
> > > +  // CompositorParent to think we are, so we pass aRenderToEGLSurface = false.
> > > +  return new CompositorParent(this, false, aSurfaceWidth, aSurfaceHeight);
> > 
> > I would like to know how hard this is to fix, since this just screams 'hack'.
> 
> Well, I think it is just that aRenderToEGLSurface really means
> aExternallyProvidedSurfaceSize or something, so the fix is just to rename
> the argument and corresponding member. I don't think that this flag is used
> for anything actually related to EGL.

Can we please-please-please rename it then? I would much rather prefer that to the `// Hack` comment we have there right now.

Comment 28

[Nick Cameron [:nrc]]

(In reply to Jeff Gilbert [:jgilbert] from comment #27)
> (In reply to Nick Cameron [:nrc] from comment #26)
> > (In reply to Jeff Gilbert [:jgilbert] from comment #25)
> > > Comment on attachment 740058 [details] [diff] [review]
> > > basic fixups
> > > 
> > > Review of attachment 740058 [details] [diff] [review]:
> > > -----------------------------------------------------------------
> > > 
> > > ::: widget/xpwidgets/nsBaseWidget.cpp
> > > @@ +876,5 @@
> > > >                                                      int aSurfaceHeight)
> > > >  {
> > > > +  // Even if we are using EGL, unless we are on Android, we don't want
> > > > +  // CompositorParent to think we are, so we pass aRenderToEGLSurface = false.
> > > > +  return new CompositorParent(this, false, aSurfaceWidth, aSurfaceHeight);
> > > 
> > > I would like to know how hard this is to fix, since this just screams 'hack'.
> > 
> > Well, I think it is just that aRenderToEGLSurface really means
> > aExternallyProvidedSurfaceSize or something, so the fix is just to rename
> > the argument and corresponding member. I don't think that this flag is used
> > for anything actually related to EGL.
> 
> Can we please-please-please rename it then? I would much rather prefer that
> to the `// Hack` comment we have there right now.

We certainly can, I'll make a separate patch

Comment 29

[Nick Cameron [:nrc]]

Attachment: rename RenderToEGLSurface

Comment 30

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 742876 [details] [diff] [review]
rename RenderToEGLSurface

Review of attachment 742876 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM with the one fix below.

::: gfx/layers/ipc/CompositorParent.h
@@ +43,5 @@
>    NS_INLINE_DECL_THREADSAFE_REFCOUNTING(CompositorParent)
>  
>  public:
>    CompositorParent(nsIWidget* aWidget,
> +                   bool s = false,

s/s/aUseExternalSurfaceSize/

Comment 31

[Nick Cameron [:nrc]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/476d5bc13806
https://hg.mozilla.org/integration/mozilla-inbound/rev/a9a56206a0dc

Comment 32

[Nick Cameron [:nrc]]

So, as far as I can tell, everything except WebGL works with EGL now. We should fix WebGL, and then leave this bug open to discuss if we want to support EGL in any capacity.

Comment 33

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/476d5bc13806
https://hg.mozilla.org/mozilla-central/rev/a9a56206a0dc

Comment 34

[Ian Romanick]

(In reply to Benoit Jacob [:bjacob] from comment #17)
> You may want to take a quick look at bug 863397. In particular, I'm removing
> the eglLockSurface-based optimizations there because they belong in
> dedicated TextureClient/TextureHosts rather than in
> GLContextProviderEGL.cpp. I don't know if eglLockSurface is available in
> Mesa.

It is not.  Since the spec requires the surface not be bound to a context, it will be difficult to impossible for us to implement this extension in general.

Comment 35

[antistress]

(In reply to Karl Tomlinson (:karlt) from comment #5)
> Sounds like we definitely want to move to EGL for the new OpenGL library ABI
> if/when that happens.
> 
> The NVIDIA GeForce driver might be the last thing holding us back before
> then.

NVIDIA Driver Soon Likely To Support EGL, Mir http://www.phoronix.com/scan.php?page=news_item&px=MTM5MjE

Comment 36

[AnAkkk]

"NVIDIA 334.16 Beta Supports 64-bit EGL / OpenGL ES"

http://www.phoronix.com/scan.php?page=news_item&px=MTU5NjI

Comment 37

[Johnny Robeson]

i'm sorta confused as to what is happening with this issue. Will EGL be used? If so, when?

Comment 38

[Kelsey Gilbert [:jgilbert]]

(In reply to Johnny Robeson from comment #37)
> i'm sorta confused as to what is happening with this issue. Will EGL be
> used? If so, when?

EGL will not be used by default.

Comment 39

[AnAkkk]

(In reply to Jeff Gilbert [:jgilbert] from comment #38)
> (In reply to Johnny Robeson from comment #37)
> > i'm sorta confused as to what is happening with this issue. Will EGL be
> > used? If so, when?
> 
> EGL will not be used by default.

Any reason for that? Isn't it required for wayland support?

Comment 40

[Kelsey Gilbert [:jgilbert]]

(In reply to AnAkkk from comment #39)
> (In reply to Jeff Gilbert [:jgilbert] from comment #38)
> > (In reply to Johnny Robeson from comment #37)
> > > i'm sorta confused as to what is happening with this issue. Will EGL be
> > > used? If so, when?
> > 
> > EGL will not be used by default.
> 
> Any reason for that? Isn't it required for wayland support?

I do not believe we have Wayland support by default.

Comment 41

[Morgane ”Sardem FF7” Glidic]

Is it possible to disable GLX at build time?
I tried with --with-gl-providel=EGL but this changeset[1] probably broke that option.

[1] <https://hg.mozilla.org/mozilla-central/rev/f84aedf7a62d>

Comment 42

[albertogomezmarin]

are there any wayland support? I observed that in plasma 5 with arch intel has improved much the egl backed, and with amd open source drivers is very good too, in the other hand nvidia privative drivers hasn't got any type of support yet, or not?

Comment 43

[Christian Stadelmann]

How about using the Vulkan API instead?

Comment 44

[u575260]

ftw mozilla 2017!
https://bugzilla.mozilla.org/show_bug.cgi?id=635134

Comment 45

[mirh]

> Blocks: 1215085

Shouldn't that be "depends on"?
And anyway it should be bug 1433081 now.

Comment 46

[Marco Castelluccio [:marco]]

With Wayland, we're going to use EGL (see bug 1434574).
Maybe this bug should just be duplicated to bug 1434574.

Comment 47

[Martin Stránský [:stransky] (ni? me)]

We'd need to move forward with this bug as it's last serious Wayland blocker. When building for Wayland target we have to select build-time GL which is EGL. In that case we need to also use EGL on both X11 and Wayland as it's build time switch.

In order to make Wayland builds usable, is it better to use EGL for both X11 and Wayland (and fix/enable EGL for X11) or implement run-time GL context switch to use GLX on X11 and EGL on Wayland?

Comment 48

[Martin Stránský [:stransky] (ni? me)]

EGL/Mesa performance on X11 is poor relatively to GLX implementation so it does not make sense to ship EGL/X11 builds on Linux.

Comment 49

[Hi-Angel]

(In reply to Martin Stránský [:stransky] from comment #48)
> EGL/Mesa performance on X11 is poor relatively to GLX implementation so it
> does not make sense to ship EGL/X11 builds on Linux.

Do you have some data to back this claim up? Per my understanding EGL should be mature enough with Mesa drivers to have same or even better performance. I'm just speculating, of course, but so you do.

Comment 50

[Martin Stránský [:stransky] (ni? me)]

(In reply to Hi-Angel from comment #49)
> (In reply to Martin Stránský [:stransky] from comment #48)
> > EGL/Mesa performance on X11 is poor relatively to GLX implementation so it
> > does not make sense to ship EGL/X11 builds on Linux.
> 
> Do you have some data to back this claim up? Per my understanding EGL should
> be mature enough with Mesa drivers to have same or even better performance.
> I'm just speculating, of course, but so you do.

You can compare that by yourself, build Firefox with Wayland backend and then run it on X11.

On my HW / Fedora 28 / kernel-4.16.9-300.fc28.x86_64
EGL_CLIENT_APIS: OpenGL OpenGL_ES 
GL_VERSION: OpenGL ES 3.2 Mesa 18.0.2
GL_RENDERER: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 

I use http://webglsamples.org/ for testing and the speed difference is enormous.

Beside the performance the GLX backend is fine tuned for X11 so better use it there. I don't say we can't use EGL on X11 but it means lots of work IMHO.

Comment 51

[Hi-Angel]

(In reply to Martin Stránský [:stransky] from comment #50)
> (In reply to Hi-Angel from comment #49)
> > (In reply to Martin Stránský [:stransky] from comment #48)
> > > EGL/Mesa performance on X11 is poor relatively to GLX implementation so it
> > > does not make sense to ship EGL/X11 builds on Linux.
> > 
> > Do you have some data to back this claim up? Per my understanding EGL should
> > be mature enough with Mesa drivers to have same or even better performance.
> > I'm just speculating, of course, but so you do.
> 
> You can compare that by yourself, build Firefox with Wayland backend and
> then run it on X11.
> 
> On my HW / Fedora 28 / kernel-4.16.9-300.fc28.x86_64
> EGL_CLIENT_APIS: OpenGL OpenGL_ES 
> GL_VERSION: OpenGL ES 3.2 Mesa 18.0.2
> GL_RENDERER: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 
> 
> I use http://webglsamples.org/ for testing and the speed difference is
> enormous.
> 
> Beside the performance the GLX backend is fine tuned for X11 so better use
> it there. I don't say we can't use EGL on X11 but it means lots of work IMHO.

FTR: I asked on #radeon channel of Freenode, and I've got the following answers (picked out as there was an irrelevant discussion too). The TL;DR being that Firefox could to be using EGL wrong.

--------

[15:44:53] <Hi-Angel> Does anybody know how GLX to EGL compares in performance? I couldn't find benchmarks, and I saw a message where Firefox devs considering to not enable EGL on X11 by default, allegedly because Mesa/EGL performance is worse than GLX. I wonder, how true is that?
[15:59:25] <iive> Hi-Angel, i'm not specialist, but I think that the Xorg 2D acceleration for all new cards is done through glamor, that is using EGL.
[16:04:04] <Hi-Angel> Hah, good point! Judging by their reply https://bugzilla.mozilla.org/show_bug.cgi?id=788319#c50 could be because they're using Intel GPU, whose DDX driver doesn't use Glamor.
[17:32:19] <MrCooper> Hi-Angel: there's no inherent reason why performance would be any different between EGL and GLX; it sounds like maybe Firefox ends up using different functionality in each case
[17:33:17] <Hi-Angel> MrCooper, is it the same on Intel GPU? The Firefox dev answered, and he turns out to have tested with Intel GPU.
[17:34:15] <iive> i think glamor has been developed on intel gpu, it is just a matter if they do use it.
[17:34:39] <MrCooper> Hi-Angel: should be the same; I think he really needs to provide more information about his findings
[17:34:56] <MrCooper> iive: the modesetting driver uses glamor, xf86-video-intel doesn't
[17:35:50] <MrCooper> iive: anyway, there could theoretically be a difference between EGL as used by glamor, and EGL on X11 as used by Firefox

Comment 52

[Piotr]

Wayland is the Gnu/Linux future. Actually many distributions use Wayland by default nowadays. Not improving EGL support (performance, stability) means Firefox can't keep up with Gnu/Linux development and stays behind. Guess what happens when the speed difference between Wayland/Firefox and Wayland/Chrome is going to be enormous in the foreseeable future?

Comment 53

[Piotr]

Wayland is the Gnu/Linux future. Actually many distributions use Wayland by default nowadays. Not improving EGL support (performance, stability) means Firefox can't keep up with Gnu/Linux development and stays behind. Guess what happens when the speed difference between Wayland/Firefox and Wayland/Chrome is going to be enormous in the foreseeable future?

Comment 54

[Yariv]

(In reply to Martin Stránský [:stransky] from comment #48)
> EGL/Mesa performance on X11 is poor relatively to GLX implementation so it
> does not make sense to ship EGL/X11 builds on Linux.

A guy on phoronix said that on when EGL is enabled, Firefox is using GLES rather than 'desktop' OpenGL: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1026675-firefox-developers-still-hesitant-about-using-egl-over-glx-on-x11-linux?p=1026709#post1026709 

This could explain the big performance difference.

Comment 55

[Martin Stránský [:stransky] (ni? me)]

(In reply to ame from comment #54)
> (In reply to Martin Stránský [:stransky] from comment #48)
> > EGL/Mesa performance on X11 is poor relatively to GLX implementation so it
> > does not make sense to ship EGL/X11 builds on Linux.
> 
> A guy on phoronix said that on when EGL is enabled, Firefox is using GLES
> rather than 'desktop' OpenGL:
> https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/
> 1026675-firefox-developers-still-hesitant-about-using-egl-over-glx-on-x11-
> linux?p=1026709#post1026709 
> 
> This could explain the big performance difference.

Sure, I didn't spend much time with that.

*anybody* can compile firefox with "ac_add_options --enable-default-toolkit=cairo-gtk3-wayland" and investigate why the EGL is slow/broken on X11/Wayland. I may be actually wrong and EGL works fine (you may still need to set webgl.force-enabled).

As I said I din't spend much time with that as my primary goal is to have at least *some* WebGL support.

Comment 56

[Martin Stránský [:stransky] (ni? me)]

No longer blocks Wayland - that builds use GLX for X11 and EGL for Wayland.

Comment 57

[Robert Mader [:rmader]]

Can we make this bug dependent on bug 1474281 ?
It might fix the observed bad performance.

Comment 58

[Darkspirit]

Wrote a small summary in bug 1010527 comment 27.

Comment 60

[Robert Mader [:rmader]]

Short question concerning the flash-plugin: does it work with the EGL backend? AFAIK the plan is to support it until the end of 2020 (which also blocks us from removing the leftovers of GTK2).

Comment 61

[Darkspirit]

(Flash is force-disabled on Wayland backend (bug 1548475). Enabling Wayland backend by default (bug 1543600) depends on Flash removal (bug 1455897) with Nightly ~84 in October.
IMHO, X11 Flash users should be forced to keep using Basic compositor (Skia) if it doesn't work with EGL, or GLX be kept alive until then (EGL by pref or env var). Skia removal depends on WebRender's software GL backend (bug 1601053).)

Comment 62

[Kelsey Gilbert [:jgilbert]]

Skia has more dependencies than Basic Layers, so WR-SW obsoletes only Basic Layers.

Comment 63

[Martin Stránský [:stransky] (ni? me)]

As flash plugin is Gtk2 and IMHO has it's own connection to X11 display it may work with any GL backend on Firefox side. AFAIK flash plugin is tied to firefox by X11 socket (or whatever the name is - https://developer.gnome.org/gtk2/stable/GtkPlug.html) and does not interact by Firefox directly (and it's also sandboxed).

Comment 64

[Robert Mader [:rmader]]

With bug 1474281 done I'm tinkering with this now, mainly so we can have clean unified Webrender partial damage using EGL_KHR_swap_buffers_with_damage and potentially EGL_EXT_buffer_age (bug 1620076).

Jeff, how would you prefer this to work? Choosing via build time option, env variable or about:config option (or even remove GLX altogether)? I guess env variable would be the most pleasant option for the moment?

Comment 65

[Darkspirit]

IMHO the huge advantage of an env var is that it can apply to all profiles at once which makes testing easier. Wayland testing already works good this way. Something like PR_GetEnv("MOZ_USE_EGL") could be used for testing. Then, when it's getting enabled by default it should be inverted to MOZ_USE_GLX. (Or something like MOZ_GL=EGL, I don't know.)

Comment 66

[pasik]

What's missing here? It'd be nice to start testing firefox with EGL on X11 aswell. Environment variable sounds good to me, for the time being.

Comment 67

[Robert Mader [:rmader]]

(In reply to pasik from comment #66)

What's missing here? It'd be nice to start testing firefox with EGL on X11 aswell. Environment variable sounds good to me, for the time being.

I've been playing with it and it's easy to get working for webgl, but I haven't got it working for WR or gl layers yet. There seem to be a bunch of implicit assumptions and checks all over the place and I don't have that much time to spent on FF. So feel free to jump in @ anyone. I hope to get something working soon, but there will likely be quite a bit of cleanup necessary if I see things right :/

Comment 68

[pasik]

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

(In reply to pasik from comment #66)

What's missing here? It'd be nice to start testing firefox with EGL on X11 aswell. Environment variable sounds good to me, for the time being.

I've been playing with it and it's easy to get working for webgl, but I haven't got it working for WR or gl layers yet. There seem to be a bunch of implicit assumptions and checks all over the place and I don't have that much time to spent on FF. So feel free to jump in @ anyone. I hope to get something working soon, but there will likely be quite a bit of cleanup necessary if I see things right :/

Ok. Are your initial/wip patches available somewhere, as a starting point for others? Thanks!

Comment 69

[Robert Mader [:rmader]]

Attachment: Bug 788319 - WIP: Use EGL on X11

Comment 70

[Robert Mader [:rmader]]

(In reply to pasik from comment #68)

Ok. Are your initial/wip patches available somewhere, as a starting point for others? Thanks!

The above patch includes the clean part and can hopefully help people get going. I've got plenty more try/error/debug stuff but that's probably not very helpful atm.

Comment 71

[mirh]

Ehrm.. Maybe I'm missing something, but shouldn't that UseGLX also check for EGL availability to begin with?
I can think to nvidia 304 cards as not supporting it (and maybe also 340 ones, but I'm not sure), despite working pretty nicely with firefox.

Comment 72

[Darkspirit]

Mesa/Nouveau works fine. EGL with proprietary Nvidia is available since 331.13 BETA from 4 October 2013.
There is a proprietary legacy EGL package (https://packages.debian.org/en/stable/libegl1-nvidia-legacy-340xx), it supports 11 year old Nvidia cards (https://packages.debian.org/en/stable/nvidia-legacy-340xx-driver).
There shouldn't be any fallback to GLX. GLX support should be removed at some point. Currently, everyone uses software rendering by default. It wouldn't be a regression if, in addition, old or broken drivers had to be blocked. Don't forget that WebRender anyway needs OpenGL 3.2, otherwise Firefox has to use software rendering with Skia (and later bug 1601053).

Comment 73

[mirh]

Mesa/Nouveau may even work fine, but it's not a mystery that DRM/nouveau is a complete disaster.
And the thing with 340 is that even if 334.16 was the first 64-bit EGL.. That was still GLES-only, and other improvements were in-between (which could or could not be needed, this is what I was wondering).

Comment 74

[Darkspirit]

(In reply to mirh from comment #73)

Mesa/Nouveau may even work fine, but it's not a mystery that DRM/nouveau is a complete disaster.

X11 would just share the Wayland codepath. So far I haven't tested DMABUF WebGL and DMABUF VAAPI with Nouveau (disaster?) and proprietary Nvidia (likely not working at all?). If DMABUF is enabled, but not supported, the regular WebGL code path is used. One can only hope that Nvidia improves their open-source driver.

improvements were in-between (which could or could not be needed, this is what I was wondering).

Thanks! It sounds the current 257.21 baseline should be increased to at least 343.13 (only relevant for WebGL).
There is another more recent legacy driver: libegl1-nvidia-legacy-390xx.

Comment 75

[Robert Mader [:rmader]]

Site note while working on it: theres still no equivalent to GLX_MESA_query_renderer` to get vendor and device IDs. I opened an issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2976

Atm we use GLX even on Wayland if available, in order to e.g. whitelist devices for Webrender rollout. On Gnome Shell the Xwayland on demand feature is getting closer to get enabled by default - so we'd need to start up Xwayland together with FF just to query those two IDs :(

Comment 76

[Rinat]

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

DMABUF <...> with <...> proprietary Nvidia (likely not working at all?).

DMABUF kernel-level API is still GPL-only, exported with EXPORT_SYMBOL_GPL() which prevents NVIDIA's kernel blob from using it. Probability of changing DMABUF licensing restrictions from kernel side is very low, with no movements in that direction since DMABUF was added. Unless NVIDIA opens their kernel-level driver part under GPL-compatible terms like AMD did, there will be no DMABUF with NVIDIA's proprietary drivers.

One can only hope that Nvidia improves their open-source driver.

As far as I know, NVIDIA's open source driver was 2d-only, not-really-readable, and was deprecated by NVIDIA in 2010.
Nouveau is not developed by NVIDIA.

Comment 77

[Darkspirit]

(offtopic) Yes, DMABUF is GPL-only. Nvidia could, for example, increase their contributions to Nouveau to serve their customers' needs.

Edit:
The EGL transition is orthogonal to the recently added DMABUF feature for Mesa users.
DMABUF VAAPI is for laptops with integrated graphics, maintained by RedHat for Wayland. It can be extended to X11 if it uses DMABUF as well. Desktops with proprietary Nvidia drivers are powerful enough to keep software decoding if Nvidia leaves their users behind by not supporting it.
DMABUF WebGL is an enhancement for Mesa users. Proprietary Nvidia won't be regressed from status quo.

Comment 78

[Rinat]

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

(offtopic) Yes, DMABUF is GPL-only. Nvidia could, for example, increase their contributions to Nouveau to serve their customers' needs.

(offtopic) Please, unhide my previous comment as it wasn't off-topic. That's a fact: installations with proprietary NVIDIA driver's won't get DMABUF sharing. You may not like it, you may say what NVIDIA could and should do, but reality is not going to change only because you decided it should. I'd like NVIDIA to increase their Nouveau efforts maybe more than you do. But is it going to make any difference?

Please, don't hide unpleasant facts just because you personally find them unpleasant.

Comment 79

[Robert Mader [:rmader]]

Attachment: Bug 788319 - WIP: Cleanups for glxtest

• prefere GL on EGL and use GLES only as fallback
• preparations to avoid using GLX
• some random cleanups

Comment 80

[Robert Mader [:rmader]]

(In reply to Rinat from comment #78)

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

(offtopic) Yes, DMABUF is GPL-only. Nvidia could, for example, increase their contributions to Nouveau to serve their customers' needs.

(offtopic) Please, unhide my previous comment as it wasn't off-topic. That's a fact: installations with proprietary NVIDIA driver's won't get DMABUF sharing. You may not like it, you may say what NVIDIA could and should do, but reality is not going to change only because you decided it should. I'd like NVIDIA to increase their Nouveau efforts maybe more than you do. But is it going to make any difference?

Please, don't hide unpleasant facts just because you personally find them unpleasant.

Can we please keep this bug about the effort to use EGL on X11? DMABUF related discussions can go to bug 1619523.

Apart from that: thanks for stepping up trying to implement DMABUF sharing on X11, Rinat!

Comment 81

[Rinat]

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

Apart from that: thanks for stepping up trying to implement DMABUF sharing on X11, Rinat!

Sorry, I'm not working on DMABUF sharing. That cannot be even started until your work on EGL is finished.
The working prototype I have, is using X11 Pixmaps to share images between processes, since most of the required functionality is already in the code.

Can we please keep this bug about the effort to use EGL on X11? DMABUF related discussions can go to bug 1619523.

I was saying that despite EGL is hopefully available with NVIDIA's proprietary drivers, hard-switching to EGL will degrade WebGL performance significantly there because images will be shared through reading textures back to the CPU memory.
Please consider keeping GLX as a fallback.

Sorry for the noise, I'll stop.

Comment 82

[Robert Mader [:rmader]]

(In reply to Rinat from comment #81)

I was saying that despite EGL is hopefully available with NVIDIA's proprietary drivers, hard-switching to EGL will degrade WebGL performance significantly there because images will be shared through reading textures back to the CPU memory.
Please consider keeping GLX as a fallback.

Sorry for the noise, I'll stop.

This is perfectly on topic. Some notes on this:

• I'm not quite following why switching to EGL would degrade performance - using pixmaps for sharing would still work, right? Further more, we currently don't even use it by default because of bug 1193015 - a NVidia driver specific bug - and if I read it right it might even work better with EGL. Could you elaborate on this?
• the main reason why I would like to use EGL is to make it easy to enable partial damage with Webrender, which in many scenarios can be a major performance improvement. So the GLX implementation will much less efficient in many common scenarios (see 1 for context) or require it's own partial damage implementation - the later potentially being a lot of work. Assuming that the later does not happen and EGL can't provide something that GLX does, we'd end up with an optional feature which at best is a trade-off.
• removing GLX support as far out of scope if this bug - getting EGL support to work is certainly the first step, with everything else requiring further evaluation and investigation - thanks for raising concerns in that regard.

1: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/

Comment 83

[Rinat]

using pixmaps for sharing would still work

You are right. I confused EGL with DMABUF for some reason. This bug was mentioned in the context of DMABUF discussion, so maybe that's why.

X11 Pixmap sharing should work as long as processes can interact with such pixmaps. EGL transition was also mentioned in the context of reducing number of X11 connections, since it should be possible to get EGL context from DRM connection, for example. And if there are no X11 connections in a process, no X11 Pixmap operations are available.

bug 1193015

As far as I know, GLX Pixmaps and X11 Pixmap are not the same thing. I don't remember if I ever tried GLX Pixmap sharing. So, I'm not sure about this either.

Comment 84

[pasik]

So can we conclude the plan forward is to add an option (env var) which allows choosing X11 with EGL (instead of the default GLX), so that it's possible to start testing the EGL bits with X11, and more code paths and features can be common/shared between X11 and Wayland more easily, such as the mentioned partial damage support, ffmpeg/vaapi/dmabuf, etc.

Comment 85

[Darkspirit]

If try builds are green and local testing looks good, it might be fine to merge EGL enabled by default and allow switching back to GLX by MOZ_USE_GLX env var. X11 has a GPU process, an edge case problem like surfman had wouldn't break Nightly.

Comment 86

[albertogomezmarin]

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

If try builds are green and local testing looks good, it might be fine to merge EGL enabled by default and allow switching back to GLX by MOZ_USE_GLX env var. X11 has a GPU process, an edge case problem like surfman had wouldn't break Firefox.

I am not sure if that can be good for stable users. I think we can and should wait until more testing is done until we can change that behaviour( i am not developper anywais and I am not working to mozilla but IMHO)

Comment 87

[Robert Mader [:rmader]]

Status update: just got Webrender to start with EGL for the first time. Only the first frame though and only with gpu process disabled (so like on Wayland). So some progress :)

Comment 88

[Robert Mader [:rmader]]

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

Status update: just got Webrender to start with EGL for the first time. Only the first frame though and only with gpu process disabled (so like on Wayland). So some progress :)

Now got it running properly for both WR and OGL (with gpu process disabled and minus bugs). Will clean up what I have and post in a couple of days - then I'll probably need some input people more familiar with the materia.

Comment 89

[Kelsey Gilbert [:jgilbert]]

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

With bug 1474281 done I'm tinkering with this now, mainly so we can have clean unified Webrender partial damage using EGL_KHR_swap_buffers_with_damage and potentially EGL_EXT_buffer_age (bug 1620076).

Jeff, how would you prefer this to work? Choosing via build time option, env variable or about:config option (or even remove GLX altogether)? I guess env variable would be the most pleasant option for the moment?

Not a build var.
Prefs are best, because we automatically see them in crashreports. Prefs are also preserved across restarts.
We primarily use envvars for settings that we don't want to persist across restarts.

swap_buffers_with_damage/buffer_age must be pref-disableable until we no longer support running without them. (this prevents chemspills, since we can ship pref updates)

Comment 90

[Robert Mader [:rmader]]

With bug 1640048 landed I would like to invite everyone following this thread to help testing. All what's needed is to start the upcoming nightly with the MOZ_X11_EGL env variable (e.g. MOZ_X11_EGL=1 ./firefox). The more feedback we get, the earlier we can be confident to enable it by default, which in turn helps greatly with Webrender and DMABUF/VAAPI enablement on X11. Thanks! :)

Comment 91

[Robert Mader [:rmader]]

Attachment: Bug 788319 - Enable EGL backend by default on X11

The GLX backend can still be used by setting the MOZ_X11_GLX
env var.

Comment 92

[Stebs]

Apart MOZ_X11_EGL=1, I also had to set media.ffmpeg.vaapi.enabled;true
But then it worked fine with no problems so far and noticeable less CPU-load!
Radeon RX 580 Series, mesa/radeonsi 20.1.3.0

With amd GPUs, while the video is running, also watch the second last line (UVD: ...) with:
sudo watch -n '0.1' cat '/sys/kernel/debug/dri/0/amdgpu_pm_info'

Thanks to all who made this possible :)

Comment 93

[klk745]

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

With bug 1640048 landed I would like to invite everyone following this thread to help testing. All what's needed is to start the upcoming nightly with the MOZ_X11_EGL env variable (e.g. MOZ_X11_EGL=1 ./firefox). The more feedback we get, the earlier we can be confident to enable it by default, which in turn helps greatly with Webrender and DMABUF/VAAPI enablement on X11. Thanks! :)

I'd like to report that EGL works fine on Firefox 84 on a Ryzen Renoir APU (libegl-mesa0 20.0.8-0ubuntu1~20.04.1) running Xfce (no Wayland). I did 2 hours of YT 4K videos in PiP mode while browsing the web.
Aside from MOZ_X11_EGL=1 on the command line, only media.ffmpeg.vaapi.enabled, gfx.webrender.all, layers.acceleration.force-enabled had to be set to true in about:config.

It should be safe to enable this for production use, maybe by migrating MOZ_X11_EGL to a boolean value in about:config as first step.

Comment 94

[Paul Menzel]

(In reply to klk745 from comment #93)

I'd like to report that EGL works fine on Firefox 84 on a Ryzen Renoir APU (libegl-mesa0 20.0.8-0ubuntu1~20.04.1) running Xfce (no Wayland). I did 2 hours of YT 4K videos in PiP mode while browsing the web.
Aside from MOZ_X11_EGL=1 on the command line, only media.ffmpeg.vaapi.enabled, gfx.webrender.all, layers.acceleration.force-enabled had to be set to true in about:config.

Thank you for testing. Why do you need layers.acceleration.force-enabled? What does not work without it?

Comment 95

[klk745]

(In reply to Paul Menzel from comment #94)

Thank you for testing. Why do you need layers.acceleration.force-enabled? What does not work without it?

It's not necessary but at least in my configuration it further reduces the CPU load in top when playing a 4K video on YT:
~200-300% (stock FF84)
~30-50% (MOZ_X11_EGL=1, media.ffmpeg.vaapi.enabled = true, gfx.webrender.all = true)
~20-30% (the above plus layers.acceleration.force-enabled = true)

Comment 96

[Paul Menzel]

(In reply to klk745 from comment #95)

(In reply to Paul Menzel from comment #94)

Thank you for testing. Why do you need layers.acceleration.force-enabled? What does not work without it?

It's not necessary but at least in my configuration it further reduces the CPU load in top when playing a 4K video on YT:
~200-300% (stock FF84)
~30-50% (MOZ_X11_EGL=1, media.ffmpeg.vaapi.enabled = true, gfx.webrender.all = true)
~20-30% (the above plus layers.acceleration.force-enabled = true)

Interesting. Do you see any differences in about:support or RadeonTop, for example? If nobody else answers in the next day, could you please create a separate issue for that, so that layers.acceleration is automatically set for your configuration?

Comment 97

[Robert Mader [:rmader]]

It's indeed surprising that layers.acceleration.force-enabled has any effect when WR is enabled - given that it enables the OpenGL compositor, which is replaced by WR. It's also in the process of getting removed from FF - for the same reason. So any indication of it having any effect is rather a bug to be investigated.

Concerning enabling EGL by default: this is tracked in bug 1677203 - the biggest blocker ATM is updating the testing infrastructure. Apart from that there are a few corner cases here and there to be taken care of (e.g. multi-gpu and dmabuf).

Comment 98

[klk745]

(In reply to Robert Mader from comment #97)

So any indication of it having any effect is rather a bug to be investigated.

I'm on Ubuntu's 5.8 HWE kernel in Focal, which is required for my Renoir APU to run smoothly - not sure if that kernel might make a difference, just in case someone wants to test in the same environment.

(In reply to Paul Menzel from comment #96)

Interesting. Do you see any differences in about:support or RadeonTop, for example?

radeontop 1.2 in Ubuntu doesn't seem to support Renoir APUs (4350G/4650g/4750G) yet.
In about:support only the values for HW_COMPOSITING and OPENGL_COMPOSITING change with layers.acceleration.force-enabled:

130d129
< "layers.acceleration.force-enabled": true,
588c587
< "status": "force_enabled",

      "status": "available",

593,597d591
< },
< {
< "type": "user",
< "status": "force_enabled",
< "message": "Force-enabled by pref"
604c598
< "status": "force_enabled",

      "status": "available",

609,613d602
< },
< {
< "type": "user",
< "status": "force_enabled",
< "message": "Force-enabled by pref"

Comment 99

[klk745]

Apologies, I think I need to correct myself:
I don't see anymore noticeable difference between the two settings after doing several 5 minute long test viewings while watching top.
I guess I simply ran into some higher peak readings earlier - observing top is really not the right tool to profile such cases exactly.

In any case thanks for the hard work you all put into this EGL/VAAPI/WR/VP9 HW decoding chain over the years.
It will enable 4K video without framedrops, save a lot of power for all X11 users and drastically increase battery life for laptop users when watching even only in 1440p on YT.

Comment 100

[Darkspirit]

Nvidia news: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-DMA-BUF-Wayland-KDE
https://bugs.kde.org/show_bug.cgi?id=428089#c2

Incidentally, we're currently working on driver-side support for passing buffers as dma-bufs, and once that's ready we could transition egl-wayland away from using EGLStreams. Then it should be possible to remove all of the EglStreamTexture stuff from kwin.

Comment 101

[lexlexlex]

I see this has been considered to be a fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1720634, but this isn't a viable fix for that.

I've updated to Firefox Nightly 2021-09-22 today to test it. The result of my testing shows that it makes my Firefox run at the wrong refresh rate. My display runs at 59.95 Hz and Firefox with this change runs at 60 Hz, causing repeated dropped frames periodically, even with only 1 window animating. I can see this happening in normal scrolling, and see it clearly on vsynctester.com.

It's not properly synchronizing to my refresh rate, unlike whatever Firefox was doing before this change with WebRender. Therefore, I would like to go back to the previous method for now and keep using the layout.frame_rate 0 workaround I described in the issue ticket I linked above.

Attached after this is my about:support info.

Comment 102

[lexlexlex]

Attachment: About:support info from Nightly 94 with EGL refresh rate issue