<a class="header-button" href="https://bugzilla-dev.allizom.org/home" title="Go to home page"> Bugzilla

Reporter

Comment 2

•

2 years ago

EGL/Xwayland:

"last good" = good
MOZ_ENABLE_WAYLAND=0 mozregression --repo autoland --launch aba9dab44bb878b46f9a1c57b1dae3cbbeeb0166 --pref gfx.webrender.software:true gfx.webrender.software.opengl:true -a about:support
"first bad" = good
MOZ_ENABLE_WAYLAND=0 mozregression --repo autoland --launch 56620e525a7cafd3f4f9cf2bb91bcc2fd678639f --pref gfx.webrender.software:true gfx.webrender.software.opengl:true -a about:support

GLX/Xwayland:

"last good" = crash
MOZ_ENABLE_WAYLAND=0 mozregression --repo autoland --launch aba9dab44bb878b46f9a1c57b1dae3cbbeeb0166 --pref gfx.x11-egl.force-disabled:true gfx.webrender.software:true gfx.webrender.software.opengl:true -a about:support
"first bad" = crash
MOZ_ENABLE_WAYLAND=0 mozregression --repo autoland --launch 56620e525a7cafd3f4f9cf2bb91bcc2fd678639f --pref gfx.x11-egl.force-disabled:true gfx.webrender.software:true gfx.webrender.software.opengl:true -a about:support
I will put GLX/Xwayland regression range into bug 1745582.

Reporter

Comment 3

•

2 years ago

SW WR OpenGL/EGL/Xwayland has been affected by bug 1635186 comment 52
And when SW WR OpenGL/GLX/Xwayland didn't crash before bug 1762424, it froze and filled the RAM:
(Darkspirit from bug 1745582 comment 8)

GLX==bad:
mozregression --launch 2021-12-14 --pref gfx.x11-egl.force-disabled:true gfx.webrender.software:true gfx.webrender.software.opengl:true -a about:support

I could reproduce above hang/memory growth with above command on KDE (X)Wayland, Debian Testing, Intel.
Btw, this kind of frozen rendering feels like bug 1796960. Does it somehow use RenderCompositorOGL instead of RenderCompositorEGL?
Consider removing SW WR OpenGL support from MOZ_WIDGET_GTK:
Revert https://hg.mozilla.org/mozilla-central/rev/cf09ffcb9a9e
and put the whole pref behind MOZ_WIDGET_ANDROID:
https://searchfox.org/mozilla-central/rev/cde3d4a8d228491e8b7f1bd94c63bbe039850696/modules/libpref/init/StaticPrefList.yaml#6776
https://searchfox.org/mozilla-central/search?q=software_opengl
```
#if defined(MOZ_WIDGET_ANDROID)
- name: gfx.webrender.software.opengl
  type: bool
  value: true
  mirror: once
#endif
```

Summary: SW WR OpenGL startup crash on Wayland, but not on Xwayland → SW WR OpenGL startup crash on Wayland, but not on Xwayland. Consider removing SW WR OpenGL support from MOZ_WIDGET_GTK as it has always been broken in some way.

Reporter

Updated

•

2 years ago

Duplicate of this bug: 1745582

Comment 5

•

1 years ago

Darkspirit, do I understand correctly that this isn't default SW WR setup but you need to flip gfx.webrender.software.opengl to true to trigger it?
Thanks.

Flags: needinfo?(stransky) → needinfo?(jan)

Comment 6

•

1 years ago

Also I wonder is there any benefit to run SW WR on OpenGL? Why not to run regular Webrender then?

Reporter

Comment 7

•

1 years ago

(In reply to Martin Stránský [:stransky] (ni? me) from comment #5)

Darkspirit, do I understand correctly that this isn't default SW WR setup but you need to flip gfx.webrender.software.opengl to true to trigger it?
Thanks.

Yes.
SW WR OpenGL/Wayland = crash since bug 1829414.
SW WR OpenGL/EGL/Xwayland = no crash, but broken (for example, affected by bug 1635186 comment 49).
SW WR OpenGL/GLX/Xwayland = crash since bug 1762424. Before that it has been affected by bug 1745582.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

Also I wonder is there any benefit to run SW WR on OpenGL?

bug 1697443 comment 0 said "It helps to investigate SoftwareWebRender with CompositorOGL problem".
= Back then it helped to debug Android bugs on desktop Linux.

In theory, GLES 2-only Linux clients (like Raspberry Pi below 4) could use this as well, but it has always been broken in some way and now it just crashes.
Those users should better keep using regular SW WR.

Why not to run regular Webrender then?

Yes. I suggest removing this broken MOZ_WIDGET_GTK feature:

reverting https://hg.mozilla.org/mozilla-central/rev/cf09ffcb9a9e (=removing https://searchfox.org/mozilla-central/rev/af5be0d1e0ff1e44bd37896d95cca9f21d47ec9c/widget/nsBaseWidget.cpp#1399-1403)
and putting the whole pref behind ifdef MOZ_WIDGET_ANDROID:

#ifdef MOZ_WIDGET_ANDROID
- name: gfx.webrender.software.opengl
  type: bool
  value: true
  mirror: once
#endif

Flags: needinfo?(jan)

Andrew Osmond [:aosmond] (he/him)

Comment 8

•

1 years ago

Andrew, what do you think? Shall we remove SW WR with OpenGL on Linux? Does it brings any benefits?
Thanks.

Flags: needinfo?(aosmond)

Assignee

Comment 9

•

1 years ago

We don't want anyone using it in the wild, but it is useful for testing. Particularly because it can be easier to work with a local build on Linux using SWGL + OpenGL, over debugging on Android, as the two share a lot of the same plumbing in this code path.

With that said, our use case is mostly about nightly, so perhaps we could restrict it in release/beta.

Andrew Osmond [:aosmond] (he/him)

Assignee

Updated

•

1 years ago

Assignee: nobody → aosmond

Severity: -- → S4

Status: NEW → ASSIGNED

Flags: needinfo?(aosmond)

BugBot [:suhaib / :marco/ :calixte]

Comment 10

•

1 years ago

Set release status flags based on info from the regressing bug 1829414

status-firefox116: --- → affected

Andrew Osmond [:aosmond] (he/him)

Assignee

Comment 11

•

1 years ago

Attached file Bug 1836397 - Only allow OpenGL compositing on Linux in nightly and debug builds. (obsolete) (deleted) — Details

Lee Salzman [:lsalzman]

Comment 12

•

1 years ago

Sotaro, it seems like the fallback from the OpenGL layers compositor is asserting in FallbackFromAcceleration for some reason, when it should just be falling back to the SW compositor. Can you look into why this is broken?

Flags: needinfo?(sotaro.ikeda.g)

Phabricator Automation

Updated

•

1 years ago

Attachment #9337702 - Attachment is obsolete: true

Comment 13

•

1 years ago

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #9)

We don't want anyone using it in the wild, but it is useful for testing. Particularly because it can be easier to work with a local build on Linux using SWGL + OpenGL, over debugging on Android, as the two share a lot of the same plumbing in this code path.

Yes, I originally added SWGL + OpenGL on Linux for android development.

Comment 14

•

1 years ago

(In reply to Lee Salzman [:lsalzman] from comment #12)

Sotaro, it seems like the fallback from the OpenGL layers compositor is asserting in FallbackFromAcceleration for some reason, when it should just be falling back to the SW compositor. Can you look into why this is broken?

On Android, we do not want to fallback from SW-WR(OpenGL) to SW-WR. Then the fallback handling part is not implemented yet. Though it is necessary for non-Android.

https://searchfox.org/mozilla-central/rev/aec3a901e6f6b3041b5ec457c9111a042cef1fb1/gfx/webrender_bindings/RenderCompositor.cpp#189

The following parts block the falling back to the SW compositor.

Comment 15

•

1 years ago

Let's clarify what's going on here and what's root cause of the issue on Linux. We fallback from SW-WR(OpenGL) to SW-WR in case we paint too early and underlying GtkWidget is not mapped yet. That's not so big issue on X11 as we can have hidden GtkWidget/XWindow and create EGLWindow for it. But it's broken on Wayland where we can't paint to hidden GtkWidget as it's juts missing.

That's kind of race condition between window creation/mapping and painting so we may randomly fallback to SW-WR here.
The right fix on Linux is to hold rendering until GtkWidget/nsWindow is mapped/visible. When we don't fallback to from SW-WR(OpenGL) to SW-WR.

Updated

•

1 years ago

Blocks: wayland

Summary: SW WR OpenGL startup crash on Wayland, but not on Xwayland. Consider removing SW WR OpenGL support from MOZ_WIDGET_GTK as it has always been broken in some way. → [Wayland] SW WR OpenGL startup crash on Wayland

Comment 16

•

1 years ago

This is Wayland only. X11 is not affected.

Updated

•

1 years ago

Depends on: 1837938