layers.gpu-process.enabled on Windows seems to be required now, should probably ignore the pref
Categories
(Core :: Graphics, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox83 | --- | unaffected |
firefox84 | --- | fixed |
firefox85 | --- | fixed |
People
(Reporter: zombie, Assigned: sotaro)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
video/mp4
|
Details | |
(deleted),
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details |
My main profile Beta just updated to 84, and now drawing of the UI (and content to a lesser degree) flickers real bad.
See attached video.
It doesn't reproduce with a clean profile, but I managed to mozregression this push log:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=56302c29923559e7ae607cbb654b5e5d060d9329&tochange=8dbba1ce63e803c5a14bd92ce8f49541760a46f6
From that, bug 1595994 looks like an only graphics-related thing, even though it says it's about media playback.
Jean-Yves, can you please take a look?
Reporter | ||
Comment 1•4 years ago
|
||
A few more notes
- it's a windows laptop with i7 and integrated graphics.
- the profile is old, so this could be some pref I changed long ago, though I don't remember changing anything graphics-related recently.
- I think I managed to disable webrender, but the issue still persists.
Comment 2•4 years ago
|
||
Seeing it doesn't reproduce with a clean profile, I'm not sure what we can action here.
And yes, bug 1595994 is only media playback related, it's about decoding content out of process.
Bug 1595994 introduced a regression on non e10s , which was resolved in 1672420. It's the only thing related to graphics that could explain what you've described.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Bug 1668875 landed shortly before this. Emilio, please check it didn't regress this.
Reporter | ||
Comment 4•4 years ago
|
||
After a lot of trial and error, I found this is caused by the layers.gpu-process.enabled
pref. I think I remember disabling this a year+ ago because of some crashes during initial rollout.
It looks like the check for e10s from bug 1672420 is not correct, that should maybe test if there's a GPU process or not.
Or alternatively, the gpu-process pref should be ignored if it is now required for basic browser functionality at all. What do you think Jean-Yves?
Comment 5•4 years ago
|
||
This isn't my area of expertise, I'm not sure why you ni? me sorry.
Reporter | ||
Comment 6•4 years ago
|
||
It looked to me like your patch in bug 1595994 changed firefox to now require a GPU process, or maybe that your patch in bug 1672420 only removed the requirement for the non-e10s case.
I'll just reopen this to let graphics folks see if/how this needs to be addressed.
Comment 7•4 years ago
|
||
Set release status flags based on info from the regressing bug 1595994
Assignee | ||
Comment 8•4 years ago
|
||
I confirmed the problem by disabling GPU process by changing pref layers.gpu-process.enabled=false and with Direct3D 11 (Advanced Layers).
Assignee | ||
Comment 9•4 years ago
|
||
It seems that https://phabricator.services.mozilla.com/D91699 of Bug 1595994 seemed to break the problem. And bug 1672420 did not fix the problem.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
When GPU process does not exist, parent process initialize D3D devices.
https://searchfox.org/mozilla-central/rev/85b84f82489451362a351b144fe5232a8e46c61c/gfx/thebes/gfxWindowsPlatform.cpp#1451
Assignee | ||
Comment 11•4 years ago
|
||
Assignee | ||
Comment 12•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
Comment 15•4 years ago
|
||
bugherder |
Comment 16•4 years ago
|
||
The patch landed in nightly and beta is affected.
:sotaro, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 17•4 years ago
|
||
Comment on attachment 9189686 [details]
Bug 1678136 - Lazily initialize SyncObject
Beta/Release Uplift Approval Request
- User impact if declined: Rendering has problems when GPU process does not exist. It could happen with pref layers.gpu-process.enabled=false.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It changes only SyncObjectD3D11Client initialization. And its fix was already confirmed on nightly.
- String changes made/needed: None
Comment 18•4 years ago
|
||
Comment on attachment 9189686 [details]
Bug 1678136 - Lazily initialize SyncObject
Approved for 84.0b7.
Comment 19•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Description
•