Closed Bug 1653443 Opened 2 months ago Closed 2 months ago

Disable the GPU process on Linux even with hardware compositing

Categories

(Core :: Graphics: WebRender, defect)

Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox80 --- fixed

People

(Reporter: aosmond, Assigned: aosmond)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

Attachments

(1 file)

This effectively reverts bug 1549965 and disables the GPU process on Linux. We would only turn it on with OpenGL and WebRender compositing, which was for half of nightly users, and 1-2% of release users. A meta bug will be filed to track bugs preventing it from being enabled in case we ever want to turn it back on.

This effectively reverts bug 1549965 and disables the GPU
process on Linux. We would only turn it on with OpenGL and
WebRender compositing, which was for half of nightly users,
and 1-2% of release users.

See bug 1653444 for a list of bugs blocking re-enabling
the GPU process on Linux.

Depends on: 1650748
Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5df699bb72b1
Disable the GPU process on Linux even with hardware compositing. r=nical
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80

Oh. We're expecting to have a GPU process for oop-webgl.

(In reply to Jeff Gilbert [:jgilbert] from comment #4)

Oh. We're expecting to have a GPU process for oop-webgl.

Hm. I would also prefer the GPU process on Linux, if it wasn't blocking shipping WR.... We still weren't using it with basic compositing, as it would auto-disable without HW composting -- and I assumed with Mac, since there is no GPU process, we would have to support that configuration?

One thing I haven't explored is whether these blockers are something we see with EGL + X11 or EGL + Wayland, or just GLX + X11. EGL isn't quite ready yet, but might be a path forward.

Yeah, EGL could be.

We might also consider having a webgl/canvas process distinct from our gpu/compositing process. WebGL IPC is designed as standalone from the gpu process, it just happens to be there right now.
I think I might not have as clear of an idea what our process zoo looks like these days, so maybe it's best to cut webgl loose into its own process.

(In reply to Andrew Osmond [:aosmond] from comment #5)

... and I assumed with Mac, since there is no GPU process, we would have to support that configuration?
...
One thing I haven't explored is whether these blockers are something we see with EGL + X11 or EGL + Wayland, or just GLX + X11. EGL isn't quite ready yet, but might be a path forward.

Note that we also don't have the GPU process on Wayland and AFAIK there's no concept for how we could ever have.

Wayland (bug 1481405 comment 15) and macOS (bug 1372850) don't have a GPU process. Only Windows and X11 have/had one.

I was surprised that you consider to pay this painful price of main process crashes to circumvent:

Due to main process crashing, I assumed you might even see a risk in shipping WebRender with native Wayland backend (bug 1587060, bug 1543600). When I saw bug 1604412 I almost wanted to naively ask you whether it would be possible to let WebRender work in the GPU process, but use DMABUF to present in the main process to circumvent Wayland's constraint, but I really don't know what I'm talking about.

For EGL please have a look at bug 1650583 and bug 1650246.

It would be interesting if bug 1654658 only happens on certain window managers or if it's caused by prefs.
Crash reports don't contain the used window manager: bug 1645732
They also don't contain vaapi/dmabuf prefs in Telemetry > user_prefs.

I assume i3 users could be more annoyed by black borders around shaped menus: bug 1479135.
But it has always been like this, even with deprecated OpenGL compositor. So far they live with it. And they are not MVP target.

If fixing a small visual bug on non-compositing i3 has a greater importance than stability, could you disable the GPU process only on i3?
(I decided to lobby for bug 1549965 when WebRender crashed on a video site at night. It should never ever happen again. :D There is nothing more frustrating than Firefox suddenly closing. As a Nightly user I expect crashes to happen, but they shouldn't hurt so much.)

darkspirit, right now the crash volumes on WebRender + X11 are not sufficiently high for me to be worried. It was very important in the early days when we were hitting panics and nullptrs everywhere. At the end of the day, the GPU process is a very nice bonus, but there do seem to be problems with it; I believe some of those bugs have been reproduced on GNOME, not just i3. We have never actually shipped that configuration, and I imagine more bugs would shake out if we did.

My biggest concern crash wise was the OOM + shmem issue, but with bug 1582954 having landed, we should no longer see those sorts of problems on Linux, and should follow the well trodden failure paths of Windows/Mac. For images, this means they don't appear instead of a content process crash.

I know Wayland has long been promised to be the future, but it does have momentum behind it. Various distro iterations have tried (or are) shipping it by default. We can't have the GPU process there, so we do need to achieve stability without it. We manage it on Mac, and we will need to do so on Linux.

We are committed to shipping WebRender everywhere, and for the first time in a very long time, that means Linux accelerated graphics is a priority. The GPU process just bails us out if we messed up, but now we are in a position to actually fix the bugs instead of asking users to live with them. At least that is my hope :).

Regressions: 1656211
You need to log in before you can comment on or make changes to this bug.