Closed Bug 1688668 Opened 3 years ago Closed 3 years ago

Make GLLibraryEGL fallback to libGL if it cannot find libGLES

Categories

(Core :: Graphics, defect, P3)

Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox88 --- fixed

People

(Reporter: aosmond, Assigned: aosmond)

References

Details

Attachments

(1 file)

In glxtest, we try to load libGL first, and if it isn't present, fallback to libGLES:

https://searchfox.org/mozilla-central/rev/4dac9993b609fccc87e82682614faf2a44cda306/toolkit/xre/glxtest.cpp#459

In GLLibraryEGL, we only try to load libGLES path variants:

https://searchfox.org/mozilla-central/rev/4dac9993b609fccc87e82682614faf2a44cda306/gfx/gl/GLLibraryEGL.cpp#403

Which means the glxtest can pass, allowing EGL to be used/preferred, but then we can't actually successfully load it since glxtest used libGL. The order probably doesn't matter too much.

I found this because we break the WebGL talos tests on CI as a result of being unable to load the GLES library.

Assignee: nobody → aosmond
Attachment #9199037 - Attachment description: Bug 1688668 - EGL should fallback to libGL if libGLES is not found. → Bug 1688668 - EGL should attempt to load libGL before libGLES.
Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ece826cc95e0
EGL should attempt to load libGL before libGLES. r=jgilbert
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

I don't know how important this is, but my Nightly started crashing on startup https://crash-stats.mozilla.org/report/index/d0440e3d-27d4-4953-aeb4-021490210126

Mozregression said it is because of this bug.

I'm on Manjaro with GF8600GT with 340 drivers and I've had MOZ_X11_EGL=1 set in my launcher for some reason. Removing it makes everything work fine again.

I also have gfx.webrender.force-disabled:true and layers.acceleration.force-enabled:true (because it was most stable for me) -

with MOZ_X11_EGL=1, layers.acceleration.force-enabled:false allowed Firefox to start, but entering about:support caused crash. Also some pages caused tab crashes (old.reddit.com for ex.) - https://crash-stats.mozilla.org/report/index/b1fc3f2b-8892-4fbf-9ba7-19a060210126

48:17.26 INFO: Running autoland build built on 2021-01-25 21:38:46.403000, revision 6bcd760b
48:29.32 INFO: Launching /tmp/tmpk18brh_k/firefox/firefox
48:29.32 INFO: Application command: /tmp/tmpk18brh_k/firefox/firefox --allow-downgrade -profile /tmp/tmppgwze58e.mozrunner
48:29.33 INFO: application_buildid: 20210125211827
48:29.33 INFO: application_changeset: 6bcd760b6dae46e2a5b3cbe26dbee65e259c328b
48:29.33 INFO: application_name: Firefox
48:29.33 INFO: application_repository: https://hg.mozilla.org/integration/autoland
48:29.33 INFO: application_version: 87.0a1
Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
48:50.01 INFO: Narrowed integration regression window from [be5a8ab6, ece826cc] (4 builds) to [6bcd760b, ece826cc] (2 builds) (~1 steps left)
48:50.01 INFO: No more integration revisions, bisection finished.
48:50.01 INFO: Last good revision: 6bcd760b6dae46e2a5b3cbe26dbee65e259c328b
48:50.01 INFO: First bad revision: ece826cc95e0f1bfebdb08a086637d85fa66c0b2
48:50.01 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6bcd760b6dae46e2a5b3cbe26dbee65e259c328b&tochange=ece826cc95e0f1bfebdb08a086637d85fa66c0b2

:aosmond, can you comment to Comment 4?

Flags: needinfo?(aosmond)
Regressions: 1688999

gwarser, thanks for very muchly for the report! With prior builds and MOZ_X11_EGL=1, does your about:support indicate you got WebRender/OpenGL? I filed a new bug for the crashes, but maybe I should just backout now and reland the fix to be safe.

Flags: needinfo?(aosmond) → needinfo?(gwarser)

Yes, all was fine before. I'm pretty sure WebRenderer hardware or software was correctly reported. Now with build 20210125191412, I see Compositing OpenGL (with gfx.webrender.force-disabled:true and layers.acceleration.force-enabled:true)

Note, this is very old hardware - it's even difficult now to install correct drivers in Manjaro.

Flags: needinfo?(gwarser)

I'm not really sure why I had MOZ_X11_EGL=1 set. Probably for testing video decoding, but my graphic does not even support something more advanced than h264.

Might work to change the order again, i.e. trying libGLESv2.so first.

OTOH, if this is a driver bug (one we can't fix and which might not get fixed if the driver is not updated any more), then this is probably a case where we'd rather not activate EGL in the first place. So if removing MOZ_X11_EGL=1 also fixes the issue, I'd be tempted to say we should just avoid using EGL on (old) Nvidia.

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

Might work to change the order again, i.e. trying libGLESv2.so first.

OTOH, if this is a driver bug (one we can't fix and which might not get fixed if the driver is not updated any more), then this is probably a case where we'd rather not activate EGL in the first place. So if removing MOZ_X11_EGL=1 also fixes the issue, I'd be tempted to say we should just avoid using EGL on (old) Nvidia.

I'll spin some builds tomorrow. I was considering a blocklist for EGL, it sounds like it is a worthy endeavour.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 87 Branch → ---

gwarser: FYI, from a quick look it looks to me like you'd get a much better FF experience with your card when using nouveau. You should be able to run Webrender (see bug 1563859) and in combination with EGL you'd also get much better WebGL performance and apparently hardware x264 decoding (don't have many reports about that yet). The later, i.e. fast WebGL and HWD, are currently not possible due to missing dmabuf support in the nvidia driver (apparently it's in the making). Maybe it'd be worth to give it a go :)

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

gwarser: FYI, from a quick look it looks to me like you'd get a much better FF experience with your card when using nouveau.

I tried it week ago, and it was completely unusable. Moments after launching Firefox, screen froze. I can still move my cursor, but no way to recover - restart only. 1.0.17 has been tagged (Phoronix news) - so I'm now waiting when it will be available on Manjaro.

Hmmm, Is there a chance this freezing was caused by MOZ_X11_EGL=1?

I have some experience with nouveau from few years ago. It had some issues but was usable then. For example hibernation did not work at all and there was some tearing, but maybe it will not be issue with WebRender.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:aosmond, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(jgilbert)
Flags: needinfo?(aosmond)

With bug 1689707 fixed I'd like to get this going again.

gwaser: could you give the following build a try and see if the situation has improved? https://treeherder.mozilla.org/jobs?repo=try&revision=ca5231255833ccccd5aa905f25ab0e87040d3bac

You can launch it via MOZ_X11_EGL=1 mozregression --repo try --launch ca5231255833ccccd5aa905f25ab0e87040d3bac

Independently of that, I'd really like to see this landing as there doesn't appear to be a risk for users not manually enabling MOZ_X11_EGL=1. Andrew, can we reland this?

Using your command line everything seems fine.

about:support shows: "Compositing WebRender (Software)".

With gfx.webrender.force-disabled:true and layers.acceleration.force-enabled:true also good - "Compositing OpenGL"

This is expected?

Failure Log
(#0) Error glxtest: eglBindAPI returned an error
(#1) Error glxtest: libEGL missing eglGetDisplayDriverName

(In reply to gwarser from comment #17)

Using your command line everything seems fine.

about:support shows: "Compositing WebRender (Software)".

With gfx.webrender.force-disabled:true and layers.acceleration.force-enabled:true also good - "Compositing OpenGL"

Great, much better than a crash :)

This is expected?

Failure Log
(#0) Error glxtest: eglBindAPI returned an error
(#1) Error glxtest: libEGL missing eglGetDisplayDriverName

Yes, this just says that your EGL supported is very old/broken and does not support GL contexts but only GLES. Together with the above part it means that we tried EGL, failed and fell back to GLX, which is exactly what we wanted here.

I suppose that means we can reland the patch after the freeze :)

Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/9074c4c1675d
EGL should attempt to load libGL before libGLES. r=jgilbert
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Flags: needinfo?(jgilbert)
Flags: needinfo?(aosmond)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: