[Wayland] Implement EGL support

RESOLVED FIXED

Status

()

P2
normal
RESOLVED FIXED
9 months ago
5 months ago

People

(Reporter: greg, Assigned: stransky)

Tracking

(Blocks: 1 bug)

Trunk
All
FreeBSD
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

9 months ago
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
(Reporter)

Updated

9 months ago
Blocks: 635134
Component: Untriaged → General
OS: Unspecified → FreeBSD
Hardware: Unspecified → All

Comment 1

9 months ago
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

Updated

9 months ago
Component: General → Graphics: Layers
Product: Firefox → Core
Whiteboard: [gfx-noted]
Priority: -- → P3

Comment 2

8 months ago
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 hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Reporter)

Comment 6

8 months ago
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

8 months ago
> 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.
(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.
(Assignee)

Comment 9

7 months ago
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.
(Assignee)

Updated

7 months ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P3 → P2
(Assignee)

Updated

7 months ago
Assignee: nobody → stransky
(Reporter)

Comment 10

7 months ago
(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)
(Assignee)

Comment 11

6 months ago
(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.
(Assignee)

Comment 12

6 months ago
Takuro, thanks for the patches. I', going split those to different bugs for easier review.
(Assignee)

Updated

6 months ago
Depends on: 1460255
(Assignee)

Updated

6 months ago
Depends on: 1460603
(Assignee)

Updated

6 months ago
Depends on: 1460605
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.
(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

Updated

6 months ago
Attachment #8963003 - Attachment is obsolete: true

Updated

6 months ago
Attachment #8963004 - Attachment is obsolete: true
(Assignee)

Updated

6 months ago
Depends on: 1462642

Updated

6 months ago
Depends on: 1464823
(Assignee)

Comment 15

6 months ago
(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.
Target Milestone: --- → mozilla62
(Assignee)

Updated

6 months ago
Target Milestone: mozilla62 → ---
(Assignee)

Comment 16

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

Comment 17

5 months ago
I think we're done here.
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.