Degraded performance after upgrading to Firefox 89 on Linux
Categories
(Core :: Graphics: WebRender, defect)
Tracking
()
People
(Reporter: firefoxbugs, Assigned: rmader)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
FIrefox is using significantly more CPU after upgrading from Firefox 88 to 89. The increased CPU is noticeable on loading any page, typing into the address bar, and typing into a text box like this bug report.
Actual results:
As I type this, the main Firefox process is using over 100% of one CPU and the other Firefox processes are each using around 12%.
If I load https://www.ozbargain.com.au, the main process uses around 240% for several seconds, and the remaining processes around 25%.
Consequently my laptop is running hotter and the fan makes a lot of noise every time I load a new page.
Expected results:
Lower CPU. I will downgrade to Firefox 88 to try to get some comparative numbers.
After downgrading to Firefox 88.0.1, typing into a text box peaks at around 23% of one core and typically sits at around 10%.
Loading https://www.ozbargain.com.au, the main process peaks at around 75% and falls back to ~5% after one second.
Obviously this isn't very scientific but there is clearly a significant difference.
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•3 years ago
|
||
Hi Steve, If you can reproduce this reliably, can you try mozregression to find which revision caused the regression?
I have run mozregression, which showed the problem started prior to Firefox 88. This surprises my because I have no issues with my 88.0.1 install (Gentoo distribution, firefox-bin package).
But in any case, it does identify the problematic commit.
11:20.96 INFO: Last good revision: 1c59701a68c9e52fcdc0bf02c02eb1dca962bc6f
11:20.96 INFO: First bad revision: c2a14298ecf313c001958c37d49cb5d9e6b7894a
11:20.96 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1c59701a68c9e52fcdc0bf02c02eb1dca962bc6f&tochange=c2a14298ecf313c001958c37d49cb5d9e6b7894a
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Steve, can you post the graphics section of about:support?
Updated•3 years ago
|
Comment 6•3 years ago
|
||
Ideally from 88 and 89
Assignee | ||
Comment 9•3 years ago
|
||
Interesting. So in both cases llvmpipe is used instead of a hardware driver - is that intended? Does you setup not have any hardware GPU? What changed is that we don't detect llvmpipe as a software driver any more, thus running HW-WR on llvmpipe instead of SW-WR - the later being much more optimized for running on the CPU.
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
IIUC there're two places which we should fix:
- https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#530 - we only make sure to detect that a GPU is accelerated, not the opposite
- https://searchfox.org/mozilla-central/source/widget/gtk/GfxInfo.cpp#283 - we should already detect llvmpipe as a know software driver, but it apparently doesn't work for EGL
Assignee | ||
Comment 11•3 years ago
|
||
I can reproduce this by using LIBGL_ALWAYS_SOFTWARE=1
. Looks easy to fix.
Steve: you can work around this for the time being by setting gfx.webrender.software
to true
(or by fixing your setup in case you actually do have a GPU).
Reporter | ||
Comment 12•3 years ago
|
||
I do have a GPU so clearly there is some issue with my setup. Setting gfx.webrender.software to true makes the performance go back to normal.
Thanks everyone!
Assignee | ||
Comment 13•3 years ago
|
||
We currently allow software drivers such as llvmpipe
to run HW-WR -
in nightly and apparently even in release.
Explicitly make these drivers always use SW-WR instead.
While on it, improve our detection for software drivers in glxtest.
This may become handy for new software drivers such as zink+lavapipe.
Comment 14•3 years ago
|
||
Tracking for 89, I might take a safe patch in a dot release.
Comment 15•3 years ago
|
||
Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/22f7bdbfbd92 Block Mesa software drivers for HW-WR, r=aosmond
Comment 16•3 years ago
|
||
bugherder |
Comment 17•3 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 18•3 years ago
|
||
Comment on attachment 9225062 [details]
Bug 1714069 - Block Mesa software drivers for HW-WR, r=aosmond
Beta/Release Uplift Approval Request
- User impact if declined: A small set of users will have massively reduced performance. These may be relatively common cases such as virtual machines.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Start Firefox with
LIBGL_ALWAYS_SOFTWARE=1
on Linux. Before this path, in some setups this will make us use "Webrender" instead of "Webrender (Software)". After this patch it should always use "Webrender (Software)" (or "Basic). - List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The worst thing that can happen is that some devices use SW-WR instead of HW-WR. That implies a little performance drop, but doesn't make the browser unusable.
- String changes made/needed:
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 19•3 years ago
|
||
Comment on attachment 9225062 [details]
Bug 1714069 - Block Mesa software drivers for HW-WR, r=aosmond
Beta/Release Uplift Approval Request
- User impact if declined: A small set of users will have massively reduced performance. These may be relatively common cases such as virtual machines.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Start Firefox with
LIBGL_ALWAYS_SOFTWARE=1
on Linux. Before this path, in some setups this will make us use "Webrender" instead of "Webrender (Software)". After this patch it should always use "Webrender (Software)" (or "Basic). - List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The worst thing that can happen is that some devices use SW-WR instead of HW-WR. That implies a little performance drop, but doesn't make the browser unusable.
- String changes made/needed:
Assignee | ||
Comment 20•3 years ago
|
||
@Pascal: the worst case scenario has actually happened and some devices now fall back to SW-WR that shouldn't. A patch is coming in bug 1714897.
Updated•3 years ago
|
Comment 21•3 years ago
|
||
I followed the steps from comment 19 and after update to Fx89 there is no reduced performance. @Steve C, could you please retest this on Nightly 91 to see if the issue is fixed for you?
Reporter | ||
Comment 22•3 years ago
|
||
Since I raised this issue I have fixed my environment so that hardware acceleration is working properly, and therefore I can only reproduce it by setting LIBGL_ALWAYS_SOFTWARE=1
. With that environment variable I can reproduce the issue with Firefox 89 but not with Nightly 91.
Comment 23•3 years ago
|
||
I will close this bug as verified fixed because Steve C confirms the fix on Nightly 91.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 24•3 years ago
|
||
I'll hold off on the beta uplift until the issues with amdgpu and nvidia are sorted.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 25•3 years ago
|
||
Comment on attachment 9225062 [details]
Bug 1714069 - Block Mesa software drivers for HW-WR, r=aosmond
approved for 90.0b7
Comment 26•3 years ago
|
||
bugherder uplift |
Comment 27•3 years ago
|
||
Steve, can you please verify if the issue is fixed for you on Firefox 90 as well?
Reporter | ||
Comment 28•3 years ago
|
||
Looks good, I cannot reproduce the original issue with FIrefox 90.0b7.
Comment 29•3 years ago
|
||
Thanks for looking into it, Steve!
Comment 30•3 years ago
|
||
Bug 1715902 fixed this in 89.0.1.
Updated•3 years ago
|
Description
•