1705148 - WebRender freeze on Linux with Xorg TearFree on intel graphics

Status: RESOLVED DUPLICATE of bug 1710400

(Core :: Graphics: WebRender, defect, P3)

Description

[iodreamify]

Attachment: simplescreenrecorder-2021-04-14_20.04.17.mkv

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

1. 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
2. set gfx.webrender.all to true in about:config
3. reboot for changes to take effect
4. 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

Comment 1

[iodreamify]

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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Andrew Osmond [:aosmond] (he/him)]

Does this happen with gfx.webrender.software set to true as well?

Comment 4

[iodreamify]

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

Does this happen with gfx.webrender.software set to true 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

[Andrew Osmond [:aosmond] (he/him)]

(In reply to iodreamify from comment #4)

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

Does this happen with gfx.webrender.software set to true 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

[Andrew Osmond [:aosmond] (he/him)]

Also could you attach your about:support in case it is related to a specific driver version or hardware iteration?

Comment 7

[iodreamify]

Attachment: about:support.txt

Comment 8

[iodreamify]

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

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!

seems with this combination firefox again freezes like before. setting gfx.webrender.all=false unfroze the ui again.

Comment 9

[Robert Mader [:rmader]]

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

[Jan Alexander Steffens [:heftig]]

(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?

Comment 11

[iodreamify]

Does MOZ_X11_EGL=1 help?

didn't help. same results with all combinations presented here.

Comment 12

[iodreamify]

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

[Robert Mader [:rmader]]

(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 :)

Comment 14

[iodreamify]

(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

[Robert Mader [:rmader]]

(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 16

[iodreamify]

Filed the issue

Comment 17

[Jan Alexander Steffens [:heftig]]

(In reply to iodreamify from comment #16)

Filed the issue

The issue was closed:

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

[Robert Mader [:rmader]]

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.