1438144 - [Wayland] Implement EGL support

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect, P2)

Description

[Val Packett]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180213220104

Steps to reproduce:

Run Firefox on Wayland with layers.acceleration.force-enabled or webgl force-enabled


Actual results:

Crash.

Looks like the first problem is that EGL initialization is called with EGL_DEFAULT_DISPLAY instead of a wl_display. I've attempted to fix that: https://gist.github.com/myfreeweb/99f2df1a29652c0b75f2799e4b1aad38 but that's not enough.

A wl_egl_window should be created to render EGL to a surface. (Or should GTK handle GL output?) I'm not familiar with Firefox code at all, so I couldn't make all that stuff work.


Expected results:

Wayland-EGL should be supported for accelerated compositing, WebRender and WebGL

Comment 1

[Peter Bašista]

In my case the browser does not crash with the mentioned "force" options enabled, but the window is blank and no content is visible.

For me, however, the EGL library fails to load, most probably because of some blacklist:

Attempting load of libEGL.so
[GFX1-]: Failed to load EGL library 3!
[GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT

Comment 2

[Takuro Ashie [:ashie]]

I have an experimental patch for this issue.

https://github.com/webdino/meta-browser/blob/firefox-60-wip/recipes-mozilla/firefox/firefox/wayland/egl/0003-Use-wl_egl_window-as-a-native-EGL-window-on-Wayland.patch

I've succeeded to enable layer acceleration with this patch.
(but not yet succeeded to enable WebGL)

I'll post it to reviewboard later.
I need help to improve it.

Comment 3

[Takuro Ashie [:ashie]]

Attachment: Bug 1438144 - GLLibraryEGL: Use wl_display to get EGLDisplay on Wayland

Because some drivers doesn't support EGL_DEFAULT_DISPLAY.
For example Intel's driver causes crash without this patch.

Review commit: https://reviewboard.mozilla.org/r/231850/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231850/

Comment 4

[Takuro Ashie [:ashie]]

Attachment: Bug 1438144 - Use wl_egl_window as a native EGL window on Wayland

You need to add the following prefs to enable layer acceleration:

user_pref("layers.acceleration.force-enabled", true);

Review commit: https://reviewboard.mozilla.org/r/231852/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231852/

Comment 5

[Takuro Ashie [:ashie]]

Attachment: Bug 1438144 - Repaint on resize asynchronously

Otherwise nsViewManager::Refresh() will be blocked forever when
CompositorOGL is enabled with EGL.
Note that it's a dirty hack, we should fix synchronous repaint
instead.

Review commit: https://reviewboard.mozilla.org/r/231854/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/231854/

Comment 6

[Val Packett]

Thanks! WebRender works with this too.

HiDPI support is broken though (a zoomed in fragment is displayed, most of the window is cropped out).

I looked into WebGL. Turns out wayland-egl does not support pbuffers (EGL_PBUFFER_BIT causes eglChooseConfig to not find a config). Why are pbuffers even used?! Is there no code to use FBOs? :(

Comment 7

[Takuro Ashie [:ashie]]

> I looked into WebGL. Turns out wayland-egl does not support pbuffers (EGL_PBUFFER_BIT causes eglChooseConfig to not find a config). Why are pbuffers even used?! Is there no code to use FBOs? :(

WebGL worked on Firefox 52 with a similar experimental patch (https://github.com/webdino/meta-browser/blob/firefox-52esr/recipes-mozilla/firefox/firefox/wayland/gem/egl/0036-Use-wl_egl_window-as-a-native-EGL-window-on-Wayland.patch).
I'm not yet sure about the difference between them.

Comment 8

[Hiroshi Hatake [:cosmo0920]]

(In reply to Takuro Ashie from comment #7)
> > I looked into WebGL. Turns out wayland-egl does not support pbuffers (EGL_PBUFFER_BIT causes eglChooseConfig to not find a config). Why are pbuffers even used?! Is there no code to use FBOs? :(
> 
> WebGL worked on Firefox 52 with a similar experimental patch
> (https://github.com/webdino/meta-browser/blob/firefox-52esr/recipes-mozilla/
> firefox/firefox/wayland/gem/egl/0036-Use-wl_egl_window-as-a-native-EGL-
> window-on-Wayland.patch).
> I'm not yet sure about the difference between them.

Additional comments:

On Firefox 52, e10s is disabled forcibly our target device (Renesas RZ/G1).
After disabling e10s, WebGL starts to work our embedded board because our board has EGL surface creation limits.

Comment 9

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

Thanks for the patches. We'd need that to ship complete Wayland build and we also need to make sure the EGL backend works for X11 as we can't switch GL backends run-time.

Comment 10

[Val Packett]

(In reply to Martin Stránský [:stransky] from comment #9)
> Thanks for the patches. We'd need that to ship complete Wayland build and we
> also need to make sure the EGL backend works for X11 as we can't switch GL
> backends run-time.

EGL does work on X11, though I currently need to relaunch Firefox for it to work. On the first start it says: "libEGL warning: DRI2: failed to open 128 (search paths /usr/local/lib/dri)" and falls back to software, after quitting and restarting it works (except WebGL 2, which is "blacklisted" despite force enabling layers and webgl)

Comment 11

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

(In reply to greg from comment #10)
> (In reply to Martin Stránský [:stransky] from comment #9)
> > Thanks for the patches. We'd need that to ship complete Wayland build and we
> > also need to make sure the EGL backend works for X11 as we can't switch GL
> > backends run-time.
> 
> EGL does work on X11, though I currently need to relaunch Firefox for it to
> work. On the first start it says: "libEGL warning: DRI2: failed to open 128
> (search paths /usr/local/lib/dri)" and falls back to software, after
> quitting and restarting it works (except WebGL 2, which is "blacklisted"
> despite force enabling layers and webgl)

That would be solved at Bug 1460255 - which implements GL context switch between GLX/EGL for X11 and Wayland backends. It would be easier to just use what we have for X11 than tuning EGL on X11.

Comment 12

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

Takuro, thanks for the patches. I', going split those to different bugs for easier review.

Comment 13

[Takuro Ashie [:ashie]]

Attachment: Backtrace for the infinite block issue

(In reply to Martin Stránský [:stransky] from comment #12)
> Takuro, thanks for the patches. I', going split those to different bugs for
> easier review.

Thanks :)

BTW I'm now investigating the issue in the 3rd patch (https://reviewboard.mozilla.org/r/231854/diff/1).
But I don't have enough time to continue the work...
Someone please investigate it if it's still reproduce on the recent m-c.
I attach the backtrace on firefox 60.

Comment 14

[Hiroshi Hatake [:cosmo0920]]

(In reply to greg from comment #6)
> Thanks! WebRender works with this too.
> 
> HiDPI support is broken though (a zoomed in fragment is displayed, most of
> the window is cropped out).
> 
> I looked into WebGL. Turns out wayland-egl does not support pbuffers
> (EGL_PBUFFER_BIT causes eglChooseConfig to not find a config). Why are
> pbuffers even used?! Is there no code to use FBOs? :(

Our 2nd target board (Renesas R-Car 3rd generation board; https://en.wikichip.org/wiki/renesas/r-car/m3) can work WebGL with attached patches.
This board is the one of reference board on Automotive Grade Linux(AGL).

ref: http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/machines/R-Car-Starter-Kit-gen3.html

Comment 15

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

(In reply to Takuro Ashie from comment #13)
> Created attachment 8975820 [details]
> Backtrace for the infinite block issue
> 
> (In reply to Martin Stránský [:stransky] from comment #12)
> > Takuro, thanks for the patches. I', going split those to different bugs for
> > easier review.
> 
> Thanks :)
> 
> BTW I'm now investigating the issue in the 3rd patch
> (https://reviewboard.mozilla.org/r/231854/diff/1).
> But I don't have enough time to continue the work...
> Someone please investigate it if it's still reproduce on the recent m-c.
> I attach the backtrace on firefox 60.

That's caused by race condition between Mesa SwapBuffers() and main wayland event loop. I'm almost sure that's a but at Mesa implementation - I'll post a workaround to Bug 1464823 but I'll also propose a fix to Mesa library.

Comment 16

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

We'd also need to enable EGL on Wayland (remove the blacklist) as it's disabled by default (AFAIK).

Comment 17

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

I think we're done here.

Comment 18

[Val Packett]

The "Repaint on resize asynchronously" patch from here is still necessary for me: without it, Firefox hangs in SendFlushRendering without showing any windows.

Comment 19

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

That may be Bug 1489902.