Open Bug 1474281 Opened Last year Updated 2 months ago
Make EGL-provider support OGL (additional to GLES)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180625102006 Steps to reproduce: Start the flatpak nightly on wayland, go to about:support System: Fedora 28, Gnome 3.28 - Wayland , Mesa 18.0.5, Intel Ivy-Bridge Actual results: - WebGL 1/2 Driver Version report OpenGL ES (3.0) - slower performance in webGL-demos than with desktop OpenGL Expected results: - reported driver version should be desktop OpenGL versions (3.0 or core 4.2) - similar performance in webGL-demos This issue has been raised in several places from time to time, it might be worth looking into it for good firefox wayland support. See: https://bugzilla.mozilla.org/show_bug.cgi?id=788319 comments 50-54
I'm not a hundred percent sure, but I think the OpenGL version is not only about WebGL but also about accelerated layers and webrender, making this whole topic much more important if we ever want them to be enabled on linux by default.
I' forgot to add: this is not only true for the flatpak version but also for the fedora firefox-wayland package. AFAIK it's always been like this with the EGL backend.
Are there any benchmarks? I get good performance with WebGL EGL OpenGL ES.
I just tried to make some benchmarks and can confirm that I couldn't find any performance differences for WebGL. That said, I'm actually more concerned about the Gecko OpenGL render backend and Webrender, as they are not limited to OpenGL ES as WebGL is. He are some numbers for the CanvasMark 2013 benchmark, although I'm not sure if that's the best benchmark for 2D performance (any suggestions?). Unfortunately, firefox 61 wayland on fedora 28 didn't work with layers acceleration forced on (Failed to create EGLSurface!), while it worked well in the flatpak nighly. But that would have been exactly the numbers we'd be interested in. Therefore some incomplete numbers already just for reference: stable 61 x11: opengl: 11374 basic: 11560 stable 61 wayland: basic: 11576 nighly 63 flatpak - wayland: webrender: 6501 opengl: 6938 basic: 7377 Concerning the bad numbers in nighly, I suppose there're some debug options set.
I forgot: that said I'd like to remove my claims from the beginning of bad WebGL performance. That was seemingly just a wrong impression. So the point is purely about having desktop OpenGL for the render backends.
Wow! This will be quite the coup if Mozilla releases native support for Wayland before Chromium.
This makes the egl-backend create desktop-gl contexts on non-android plattforms. I successfully tested several WebGL examples, accelerated layers and webrender under wayland/egl. I guess the most important remaining question is on which plattform we want desktop GL by default and on which ones GLES
:stransky , this one fixes bug 1500415 for me, could you have a look on it?
In order to make this save to land, can someone from the gfx-team clarify where we need GLES support? Three questions come to my mind: - apart from android, are there platforms we know which need GLES? - should we have a fallback? Check first for desktop GL, then try GLES? - should we maybe just set a compile flag which controls this?
Summary: EGL forces OpenGL ES → Make EGL-provider support OGL (additional to GLES)
jnicol said on IRC that jgilbert is the right person to talk to
(In reply to robert.mader from comment #9) > In order to make this save to land, can someone from the gfx-team clarify > where we need GLES support? > > Three questions come to my mind: > - apart from android, are there platforms we know which need GLES? Not really no. > - should we have a fallback? Check first for desktop GL, then try GLES? It's probably ok to not. > - should we maybe just set a compile flag which controls this? That seems ok to me. It's worth checking these answers with jgilbert though.
Applied the use_desktop_gl_in_egl patch, now WebRender doesn't start (and WebGL1 failed too? because of it?) (gfx.webrender.all=true, Weston master, Mesa master ~1 month old, Radeon RX 480, FreeBSD -CURRENT) Compositing: OpenGL WebGL 1 Driver Renderer: WebGL creation failed: * tryNativeGL * Exhausted GL driver options. (#0) Error Failed to compile shader: ps_text_run 0:21(12): error: extension `GL_ARB_explicit_attrib_location' unsupported in vertex shader (#1) Error wr_renderer_render: Shader(Compilation("ps_text_run", "0:21(12): error: extension `GL_ARB_explicit_attrib_location\' unsupported in vertex shader\n")) (#2) Error Compositors might be mixed (5,2) GL_ARB_explicit_attrib_location *is* present in "WebGL 2 Driver Extensions" though.
X11/GLX backend works perfectly (on the same Firefox build) with WebRender and WebGL and everything. The WebGL 1 issue doesn't seem WebRender related (same result with gfx.webrender.all=false). WebRender and WebGL 1 worked fine on GLES (until the "everything is squares" WebRender bug appeared).
Just rebased to central tip and see the very same issue (no WebGL, Webrender not starting). Will look into it
(In reply to Jeff Muizelaar [:jrmuizel] from comment #11) > (In reply to robert.mader from comment #9) > > In order to make this save to land, can someone from the gfx-team clarify > > where we need GLES support? > > > > Three questions come to my mind: > > - apart from android, are there platforms we know which need GLES? Android and ANGLE. > > - should we have a fallback? Check first for desktop GL, then try GLES? We *must* fallback to ES.
Thanks for the clarification @jrmuizel and @jgilbert! @grep: I think there are two bugs here. First of all we seem to hit bug 1489902, but that should also happen without this patch. Secondly, something has happened to the WebGL 1 path...or maybe it is even the same. I'll wait for stransky to investigate that bug again and try to change this patch to have a proper fallback in the meantime.
Another rebase and looks like the issue is gone (with the desktop GL patch at least). WebGL works, even WebRender works under Wayland again. Except there's a new (?) issue: with WebRender, I can only have one browser window working. Windows other than the first are just transparent, only the gtk shadow is visible, no content.
Rebased the patch to latest trunk but WebRender does not work for me with it.
Type: defect → enhancement
OS: Unspecified → Linux
Version: 63 Branch → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → robert.mader
You need to log in before you can comment on or make changes to this bug.