Linux should fallback to software if the GPU process is disabled due to crashes
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: aosmond, Assigned: aosmond)
References
(Blocks 2 open bugs)
Details
Attachments
(1 file)
On Windows, when we disable the GPU process, we actually disable hardware compositing and fallback to software:
We should do the same on Linux.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 1•5 years ago
|
||
If the GPU process becomes disabled due to crashes, then we should not
allow Linux to fallback from WebRender to OpenGL compositing in the
parent process. It should instead fallback to software just like
Windows. This is important because we don't support the OpenGL
compositor configuration.
Pushed by aosmond@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/74e4704a550e Disable hardware acceleration on Linux if the GPU process becomes disabled. r=rhunt
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
It is my understanding that the assumption in windows, bug 1494538, was that if you are somehow bugged enough that webrenderer fails, then there's little point in grasping at normal acceleration (also perhaps some niche condition somebody didn't want to bother too much, like in bug 1297822, but maybe I'm just reading too much into it)
But why would this entail a one-to-one correspondence between hw_compositing and webrenderer?
The former still is a prerequisite of the latter, and I can imagine plenty of situations were this would be unsupported to begin with without compromising the capabilities of the first.
(e.g. AFAIU one should just already work with ES 2.0, while the latter needs 3.1 - but also people forcing off the gpu process* for whatever reason)
*assuming that just like in windows gpu process and webrenderer are supposed to be the "same" thing
https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#2887
CCing Jan, because he seemed the one claiming that in bug 594876
(and I didn't want to further clutter that)
|
|
Assignee | |
Comment 6•5 years ago
|
||
mirh, if the GPU process is disabled due to crashing it will disable HW compositing. If you disable the GPU process via a pref, this change will have no impact -- you can still have WebRender or OpenGL compositing in the parent process. Sadly, we never officially shipped OpenGL compositing on Linux in all the years it was implemented, so relatively few users have it enabled today. My aim is to ensure we don't make that same mistake with WebRender. If/when WebRender on Linux ships officially in a release, it will supplant OpenGL compositing entirely :).
Oh, I thought that webrender was just something that you built over normal acceleration.. Instead (even though checks here and there may overlap) it completely replaces it.
Still, doesn't that bump firefox's gpu and ram minimum requirements for "a satisfactory experience"?
I mean, on Windows you may even require dx11 for webrender (which saving perhaps for some feature levels shenanigan, is higher than opengl 3.1).
But I'm under the impression that even d3d9 cards should still work with normal compositing?
(and that would also include some pretty important hardware like rpi then)
|
||
Comment 8•5 years ago
|
||
(In reply to mirh from comment #7)
(and that would also include some pretty important hardware like rpi then)
- bug 1541975
- Current Rpi uses VC4. It's not clear whether next Raspberry Pi will make use of VC5 (GLES 3.1 + Vulkan). It was written for set-top boxes:
https://www.x.org/wiki/Events/XDC2017/anholt_vc4_vc5.pdf
https://www.raspberrypi.org/forums/viewtopic.php?t=189231
https://www.phoronix.com/scan.php?page=news_item&px=VC5-V3D-Gallium3D-Default
That was just an example tbh. Intel GMA (which I see in your data report, is surprisingly quite not dead) could have done the same.
Anyway, well, if you are working on expanding the thing all the way down to ES 2.0, then please by all means.
Thanks for the explanations.
Description
•