Open Bug 788319 (linux-egl) Opened 12 years ago Updated 1 year ago

[meta] Use EGL instead of GLX on X11

Categories

(Core :: Graphics: WebRender, enhancement)

Product:
Core
Component:
Graphics: WebRender
Version:
18 Branch
Platform:
All
Linux
Type:
enhancement

Tracking

()

People

(Reporter: marco, Unassigned)

References

(Depends on 7 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta, Whiteboard: [leave open])

Attachments

(9 obsolete files) 

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."
---
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).
Blocks: wayland
This would also be an instant win for WebGL, as it runs better (faster, using less memory) on top of GLES than desktop GL.
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.
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.
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.
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.
Mesa already supports it, and, I believe, Wayland uses it.  You may encounter issues, and we look forward to your bug reports. :)
Blocks: 822518
This would also be of great important to Raspberry Pi, as their drivers only support EGL and not GLX on X11.
Blocks: 835926
Attached patch initial wip (obsolete) (deleted) — — Splinter Review 

    
    

    
  
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?

    
    

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

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
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
Flags: needinfo?(jgilbert)

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        basic fixups (obsolete) (deleted)
        — 
          — Splinter Review
      

    


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

        Attachment #738390 -
        Attachment is obsolete: true

        Attachment #740058 -
        Flags: review?(bjacob)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        WIP webgl (obsolete) (deleted)
        — 
          — Splinter Review
      

    


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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        WIP webgl (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  

        Attachment #740059 -
        Attachment is obsolete: true

    
    

    
  
(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.
Flags: needinfo?(jgilbert)

        Attachment #740058 -
        Flags: review?(bjacob) → review+

    
    

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

        Attachment #740058 -
        Flags: feedback?(ncameron)

    
    

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

    
    

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

    
  
Blocks: 865019

    
    

    
  
(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

    
  

        Attachment #740058 -
        Flags: feedback?(ncameron)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        rename RenderToEGLSurface (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  

        Attachment #742876 -
        Flags: review?(bugmail.mozilla)

    
    

    
  
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/

        Attachment #742876 -
        Flags: review?(bugmail.mozilla) → review+

    
    

    
  
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.

    
    

    
  
(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.
Depends on: 868682

    
    

    
  
(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

    
  

        Attachment #742876 -
        Flags: checkin+

    
  

        Attachment #740058 -
        Flags: checkin+

    
    

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

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

    
    

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

    
    

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

    
    

    
  
(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?

    
    

    
  
(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.
Depends on: 1202175

    
  
Depends on: 1197632

    
    

    
  
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>

    
    

    
  
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?

    
    

    
  
How about using the Vulkan API instead?

    
    

    
      
  

    
  
Blocks: 1215085

    
    

    
  
> Blocks: 1215085

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

    
    

    
  
With Wayland, we're going to use EGL (see bug 1434574).
Maybe this bug should just be duplicated to bug 1434574.
No longer blocks: 1215085
See Also:  → https://bugzilla.mozilla.org/show_bug.cgi?id=1434574

    
    

    
  
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?
Flags: needinfo?(jgilbert)

    
    

    
  
EGL/Mesa performance on X11 is poor relatively to GLX implementation so it does not make sense to ship EGL/X11 builds on Linux.
Flags: needinfo?(jgilbert)

    
    

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

    
    

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

    
    

    
  
(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

    
    

    
      
  

    
    

    
      
  

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
Wrote a small summary in bug 1010527 comment 27.


Blocks: wr-linux
No longer blocks: ogl-linux-beta
Type: defect → task

    
  
Depends on: 1570441

    
  
Blocks: 1580166

    
  
Blocks: 1620076

    
    

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



    
    

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



    
    

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



    
    

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



    
    

    
  
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?


Flags: needinfo?(jgilbert)

    
    

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



    
  
Blocks: 1479135

    
    

    
  
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.



    
    

    
  
(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 :/



    
    

    
  
(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!



    
    

    
  

      
      
      
      

        Attached file
          
        Bug 788319 - WIP: Use EGL on X11 (obsolete) (deleted)
        — 
      

    


  

    
    

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



    
    

    
  
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.



    
    

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



    
    

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



    
    

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



    
    

    
  
Site note while working on it: theres still no equivalent toGLX_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 :(



    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  

      
      
      
      

        Attached file
          
        Bug 788319 - WIP: Cleanups for glxtest (obsolete) (deleted)
        — 
      

    


  
    

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

  • preparations to avoid using GLX
    • 

  • some random cleanups
    • 




    
    

    
      
  

    
    

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



    
    

    
  
(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/



    
    

    
  


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.



    
    

    
  
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.



    
    

    
  
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.



    
    

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



    
    

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



    
    

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


Depends on: 1640048

        Attachment #9147099 -
        Attachment is obsolete: true

        Attachment #9149427 -
        Attachment is obsolete: true
Depends on: 1640053
Depends on: 1640147

    
  
Blocks: 1625070
Component: Graphics: Layers → Graphics: WebRender
Depends on: 1640779
No longer blocks: 1580166
No longer blocks: 1625070

    
    

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


Flags: needinfo?(jgilbert)

    
    

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



    
    

    
  

      
      
      
      

        Attached file
          
        Bug 788319 - Enable EGL backend by default on X11 (obsolete) (deleted)
        — 
      

    


  
The GLX backend can still be used by setting the MOZ_X11_GLX

env var.



    
  
Depends on: 1650246

    
  
Depends on: 1650583

    
    

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



        Attachment #9161098 -
        Attachment is obsolete: true

    
  
Depends on: 1663003

    
  
Depends on: 1663152

    
  
Depends on: 1663206

    
  
Depends on: 1667621
No longer depends on: 1663152
Depends on: 1669275
Depends on: 1677892

    
  
Depends on: 1678897
Type: task → enhancement

    
    

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



    
    

    
  
(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?



    
    

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



    
    

    
  
(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?



    
    

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


Depends on: wr-linux-egl-nightly

    
    

    
  
(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"



    
    

    
  
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.



    
    

    
  
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.




Alias: linux-egl
Blocks: 1678804
Depends on: 1700515

    
  
No longer depends on: 1700515
Blocks: 1600971
Blocks: 1676164
Depends on: 1702546
Depends on: 1710815
Depends on: 1712665
Depends on: 1713468
Depends on: 1717816
Depends on: 1717555

    
  
Depends on: 1719898

    
  
Depends on: 1670545
Blocks: 1719639

    
  
No longer depends on: 1710815

    
  
Blocks: slow-linux-webgl

    
  
Depends on: 1725538

    
  
Depends on: 1725624
Depends on: 1728473

    
  
Blocks: 1708943

    
  
Depends on: 1729656

    
  
Depends on: 1712969
Depends on: 1709584
Depends on: 1709585
Depends on: 1709586

    
  
Depends on: 1730822

    
  
Depends on: 1725245

    
  
Depends on: 1731125

    
  
Depends on: 1731172

    
  
Blocks: 1714633, 1716049
Keywords: meta
Summary: Consider using EGL instead of GLX with Mesa drivers → [meta] Consider using EGL instead of GLX

    
  
Blocks: 1725624
No longer depends on: 1725624
Blocks: 1703529

    
  
No longer blocks: 1703529
Summary: [meta] Consider using EGL instead of GLX → [meta] Use EGL instead of GLX on X11
Depends on: 1732002

    
    

    
      
  

    
    

    
      
  


  

    
  
Blocks: 1732365
Depends on: 1684194

    
  
Depends on: 1732580
No longer depends on: 1730822

    
  
Depends on: 1735045
Depends on: 1735939

    
  
Depends on: 1736245
Depends on: 1736621

    
  
Depends on: 1737078
Depends on: 1737428
Blocks: 1635186

    
  
Depends on: 1739259

    
  
Depends on: 1739344

    
  
Depends on: 1739611

    
  
Depends on: 1740260

    
  
Depends on: 1742533

    
  
Depends on: 1743051

    
  
Depends on: 1743255

    
  
Depends on: 1743403

    
  
Depends on: 1741330

        Attachment #740058 -
        Attachment is obsolete: true

        Attachment #742876 -
        Attachment is obsolete: true

        Attachment #740072 -
        Attachment is obsolete: true

        Attachment #9242586 -
        Attachment is obsolete: true
Depends on: 1744060
No longer depends on: 1725245
No longer depends on: 1709584
Depends on: 1744389

    
  
Depends on: 1745172

    
  
Depends on: 1751238

    
  
No longer blocks: 1716049

    
  
Severity: normal → S3

    
  
Depends on: 1813084

    
  
Depends on: 1818992

    
  
Depends on: 1709584

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: