WebRender freeze on Linux with Xorg TearFree on intel graphics
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: iodreamify, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
- Enable option Intel TearFree inside Xorg.conf file (to mitigate tearing issues on Linux) as described here: https://wiki.archlinux.org/index.php/intel_graphics#Tearing
- set gfx.webrender.all to true in about:config
- reboot for changes to take effect
- open Firefox
Actual results:
Firefox ui draws only first frame and then completely freezes.
Clicking buttons or switching tabs still seems to do things but without redrawing the ui.
Only if you minimize and restore the firefox window will it redraw the ui
The cursor only changes if you place it on input fields.
I've illustrated it in the attached video. It also happens with a clean prefix with gfx.webrender.all=true
Expected results:
Firefox draws the ui and works as usual
Reporter | ||
Comment 1•4 years ago
|
||
interestingly, on Nightly, with TearFree, Firefox ProfileManager has the same struggles redrawing the window only when moved
And Firefox doesn't launch at all. Nightly symptoms are gone when TearFree is disabled.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•4 years ago
|
||
Does this happen with gfx.webrender.software
set to true
as well?
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Andrew Osmond [:aosmond] from comment #3)
Does this happen with
gfx.webrender.software
set totrue
as well?
does not happen for this case:
gfx.webrender.software = true
gfx.webrender.all = false
and does not happen with this case either:
gfx.webrender.software=true
gfx.webrender.all=true
Comment 5•4 years ago
|
||
(In reply to iodreamify from comment #4)
(In reply to Andrew Osmond [:aosmond] from comment #3)
Does this happen with
gfx.webrender.software
set totrue
as well?does not happen for this case:
gfx.webrender.software = true
gfx.webrender.all = false
and does not happen with this case either:
gfx.webrender.software=true
gfx.webrender.all=true
Thanks, gfx.webrender.software
overrides gfx.webrender.all
so I would expect it to be the same. Reading up a bit more on the feature, could you try flipping gfx.webrender.allow-partial-present-buffer-age
to false
and see if that works (only applies with gfx.webrender.all
set to true
and gfx.webrender.software
set to false
)? Thanks!
Comment 6•4 years ago
|
||
Also could you attach your about:support in case it is related to a specific driver version or hardware iteration?
Reporter | ||
Comment 7•4 years ago
|
||
Reporter | ||
Comment 8•4 years ago
|
||
(In reply to Andrew Osmond [:aosmond] from comment #5)
Thanks,
gfx.webrender.software
overridesgfx.webrender.all
so I would expect it to be the same. Reading up a bit more on the feature, could you try flippinggfx.webrender.allow-partial-present-buffer-age
tofalse
and see if that works (only applies withgfx.webrender.all
set totrue
andgfx.webrender.software
set tofalse
)? Thanks!
seems with this combination firefox again freezes like before. setting gfx.webrender.all=false
unfroze the ui again.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 9•4 years ago
|
||
This IMO falls into the category of things we can't really fix. A non-default option on a known buggy driver for Xorg, which got ditched by most distributions is just too uncommon/legacy.
We may be able to detect the intel driver and force sw rendering. Most users use the modesetting driver these days. xrandr --listproviders
appears to be one way to detect the driver in use.
Comment 10•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #9)
A non-default option
I think the driver enables the option by default in some situations, like newer GPUs, framebuffer compression or panel self-refresh. xf86-video-amdgpu also seems to have the same option.
The option might only have an effect without a compositor?
Does MOZ_X11_EGL=1
help?
Reporter | ||
Comment 11•4 years ago
|
||
Does MOZ_X11_EGL=1 help?
didn't help. same results with all combinations presented here.
Reporter | ||
Comment 12•4 years ago
|
||
I've just tried disabling Xfce's compositor and with the compositor off and firefox with gfx.webrender.all=true
the bug seems to be gone.
If i launch firefox with the compositor on then the bug reappears. Also, toggling between compositor on and off while firefox is running the ui still freezes.
Comment 13•4 years ago
|
||
(In reply to iodreamify from comment #12)
I've just tried disabling Xfce's compositor and with the compositor off and firefox with
gfx.webrender.all=true
the bug seems to be gone.If i launch firefox with the compositor on then the bug reappears. Also, toggling between compositor on and off while firefox is running the ui still freezes.
If you have the compositor active, do you still need TearFree? IIUC it's doing something very similar. Or does your setup make it necessary for some reason? Just trying to understand why this option is still used these days :)
Reporter | ||
Comment 14•4 years ago
|
||
(In reply to Robert Mader [:rmader] from comment #13)
(In reply to iodreamify from comment #12)
I've just tried disabling Xfce's compositor and with the compositor off and firefox with
gfx.webrender.all=true
the bug seems to be gone.If i launch firefox with the compositor on then the bug reappears. Also, toggling between compositor on and off while firefox is running the ui still freezes.
If you have the compositor active, do you still need TearFree? IIUC it's doing something very similar. Or does your setup make it necessary for some reason? Just trying to understand why this option is still used these days :)
Honestly, i don't know much about these areas. But it seems the TearFree option/hack is the only thing that fixes video tearing for me on Xfce. I've just tried some more combinations, without TearFree, and it seems it doesn't matter if Xfce's compositor is running or not, i still get tearing, even if the tearing pattern changes. I have also just tried my hardware with KDE and there the compositor takes care of tearing completely without TearFree plus Webrender works with the compositor on without any problems(i didn't test webrender with TearFree on there since the need was no longer there because the tearing was gone)
So in the end i guess this is either Xfce's fault or a bug in the combination of Xfce - TearFree - Webrender. If this is too niche or too hard to fix then i understand. I just wanted to report the bug so developers are at least aware of it.
Comment 15•3 years ago
|
||
(In reply to iodreamify from comment #14)
So in the end i guess this is either Xfce's fault or a bug in the combination of Xfce - TearFree - Webrender. If this is too niche or too hard to fix then i understand. I just wanted to report the bug so developers are at least aware of it.
Highly appreciate this, thanks! To me this also sounds like a bug in the XFCE compositor - mind creating an issue there and link it here? Would love to see it fixed, especially as we're now enabling WR on XFCE by default. So we should make sure the devs there know about the issue.
Comment 17•3 years ago
|
||
(In reply to iodreamify from comment #16)
Filed the issue
It's the use of βpresentβ for vblank that breaks it. But thing is, xfwm4 is not responsible for the client redering itself, so this bug is between the driver and the client, not a bug in xfwm4.
The reason it affects xfwm4 on intel is because xfwm4 automatically selects present for vblank on intel hardware.
Closing, this is not a bug in the compositor.
Comment 18•3 years ago
|
||
so this bug is between the driver and the client
Well, sounds like it's still a problem on our side (or the driver). Not exactly sure what we should do here - potentially try to detect the driver in glxtest and disable HW-WR (or maybe just GLX based vsync?) when anything but modesetting
is detected. AFAIK the later has been the de facto standard for some years now and covers by far the most users.
Updated•3 years ago
|
Description
•