1663285 - poor performance in firefox with webrender on raspberry pi4

Status: RESOLVED FIXED

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

Description

[Leo_sk]

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

Steps to reproduce:

1. Enable gfx.webrender.all to true
2. Run 'MOZ_X11_EGL=1 firefox' in terminal

Actual results:

Firefox has visual artefacts and page load/scrolling performance is not good

Expected results:

Firefox should have launched normally without artefacts with better or comparable performance to basic compositor

Comment 1

[Leo_sk]

Also check bug 1661359

Comment 2

[Darkspirit]

Thanks! Could you take a performance profile using https://profiler.firefox.com with the Graphics preset?

about:support from bug 1661359 comment 7:

GPU #1
Active: Yes
Description: V3D 4.2
Vendor ID: 0x14e4
Device ID: 0xffff
Driver Vendor: mesa/vc4
Driver Version: 20.1.6.0
RAM: 7380
Display0: 1920x1080 default

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md

Comment 3

[Leo_sk]

Sorry for the delay. My only raspberry pi 4 is engaged in a project and I can't upload performance profile for a while. Will do so as soon as it is over

Comment 4

[vinceying113]

It would be great to get hardware WebRender working on the Pi, and I'm happy to provide any troubleshooting info that's needed. It actually almost works, and performs better than software WebRender. The issue is random parts of the screen will turn blank while browsing. When those parts of the screen aren't covered up, everything else appears to be working.

My understanding is the old layers.acceleration OpenGL backend will eventually be removed (this works fine on the Pi). If that's the case, it would be too bad to make Pi users use software WebRender, when the device is already speed constrained.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

vinceyin113, can you file a separate bug about the parts turning blank?

Comment 6

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 7

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Dave Jones]

Please let me know if I can be of any assistance on providing information for this bug; I'm happy to provide debugging information from Firefox on the Pi. For reference, I've replicated the issue with both the snap and deb packages of firefox (version 102.0.1) under Ubuntu 22.04 running under x11, xwayland, and wayland backends (though notably after setting gfx.webrender.all several of the gfx.blacklist values had to be disabled to replicate the issue).

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Dave, what prefs did you set?

Comment 10

[Dave Jones]

Hi Jeff, sorry -- missed the notification on this! I went back and tried this again with version 102.0.1 running under 22.04 LTS again. It seems my assertion about disabling the blacklist values was wrong. Simply setting "gfx.webrender.all" to "true" is sufficient to replicate the issue.

I suspect I was confused over the blacklist settings as replication is a bit variable. Starting up Firefox shows no problems initially, and I managed to scroll around for a while before the page started glitching (opening a second tab appeared to replicate the issue more quickly, but that could be coincidence). Lastly, I replicated the issue under the xwayland (default), wayland, and x11 backends so that doesn't seem to be a factor in replication at least.

Anyway, all that's necessary for replication is setting "gfx.webrender.all" to "true"; I didn't need MOZ_X11_EGL=1 to be set (I attempted runs both with and without it set, and while the console error messages differed slightly the issue could be replicated in both circumstances), and using MOZ_ENABLE_WAYLAND=1 to force the wayland backend made no difference to the replication.

If a copy of the error messages, about:support output, or profiler output would help, please let me know (I'll try and keep a closer eye on the notifications!)

Comment 11

[Jeff Muizelaar [:jrmuizel]]

It seems like this is probably an upstream mesa issue. Can you file an issue here https://gitlab.freedesktop.org/mesa/mesa/-/issues/ and report that url here?

Comment 12

[Robert Mader [:rmader]]

With bug 1730936 the detection should have become much better and with bug 1783924 HW-WR is set to ride to release on Mesa >= 22.2. So we now need to figure out if there's still rendering issues and if we need to block HW-WR a bit longer - or maybe only certain features. Comment 0 sounds like it could be a duplicate of bug 1738816.

Leo, could you try latest nightly (https://treeherder.mozilla.org/jobs?repo=try&revision=5ada11f4a0b7b20fdcd5b6ab9b9befa808026325&selectedTaskRun=cF1gruhpSpGgJHPjNrV3Hw.0 / https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cF1gruhpSpGgJHPjNrV3Hw/runs/0/artifacts/public/build/target.tar.bz2) and check if you still see issues? And if so, whether gfx.webrender.pbo-uploads=false helps?

Comment 13

[Leo_sk]

It will take me some time to test as I will need to disassemble my project and reinstall linux. I think many others who volunteered could help out here

Comment 14

[Robert Mader [:rmader]]

Looks like the main blocker for HW-WR is now bug 1784327 / https://gitlab.freedesktop.org/mesa/mesa/-/issues/7062. If any Mesa/v3d devs read this: help with that would be very appreciated :)

Comment 15

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[:gerard-majax]

Adding needinfo? on myself to remember testing that on rpi4 / ubuntu 22.04 on snap and non snap

Comment 17

[Allan Vázquez [:soymos]]

How is this going? I am a raspberry pi user and would really appreciate using firefox with hardware acceleration. I noticed that the bug report in mesa was recently closed. I am a intermediate linux user with no experience in bugzilla, but with guidance I am willing to help/test in whatever I can (also english isn't my native lenguage but mostly I can manage). Thanks

Comment 18

[:gerard-majax]

(In reply to Allan Vázquez [:soymos] from comment #17)

How is this going? I am a raspberry pi user and would really appreciate using firefox with hardware acceleration. I noticed that the bug report in mesa was recently closed. I am a intermediate linux user with no experience in bugzilla, but with guidance I am willing to help/test in whatever I can (also english isn't my native lenguage but mostly I can manage). Thanks

On my side, I have yet to find a decent way to build Firefox Snap for arm64 ...

Comment 19

[Allan Vázquez [:soymos]]

Do you mean a modified version of firefox snap Alexandre LISSY [:gerard-majax]?

Comment 20

[:gerard-majax]

(In reply to Allan Vázquez [:soymos] from comment #19)

Do you mean a modified version of firefox snap Alexandre LISSY [:gerard-majax]?

I mean just a rebuild. But on arm64. Snapcraft does not allow for cross-compilation, so one needs arm64 hardware. For rebuilding firefox, relying on rpi4 for that is going to be tedious.

Comment 21

[Allan Vázquez [:soymos]]

Ok. How can I help? I thought of contacting snapcraft for assistance, I originally found this bug because of this blog post, so I think they are also interested in solving it. Should I try that? Also, sorry for my ignorance, but why is important to rebuild for snap? wouldn't be enough if a .deb firefox tested in rpi4 worked?

Comment 22

[Allan Vázquez [:soymos]]

If it is needed, I have 5 idle rp4 right now and time for building and testing. Just need instructions.

Comment 23

[:gerard-majax]

Thanks, but the problem would not be solved by having many RPi4 :). I need to be able to rebuild a Snap as well because of its sandboxing specifics, so we can address both.

Comment 24

[:gerard-majax]

The fix should in the current dev version of Ubuntu

Comment 25

[Allan Vázquez [:soymos]]

I want to test, but use raspberry pi os debian based. I searched and found that in ubuntu the snap version is default, but there are several, do you mean the latest/edge 109.0a1?

Comment 26

[Darkspirit]

Firefox' hardware rendering (requires GLES3) on Raspberry Pi4 requires Mesa 22.2.4 (bug 1784327, bug 1783924), e.g. Debian testing/bookworm.

(In reply to Allan Vázquez [:soymos] from comment #25)

do you mean the latest/edge 109.0a1?

Yes.

Comment 27

[Allan Vázquez [:soymos]]

(In reply to Darkspirit from comment #26)

Firefox' hardware rendering (requires GLES3) on Raspberry Pi4 requires Mesa 22.2.4 (bug 1784327, bug 1783924), e.g. Debian testing/bookworm.

(In reply to Allan Vázquez [:soymos] from comment #25)

do you mean the latest/edge 109.0a1?

Yes.

This libraries are included in the snap version?

Comment 28

[Allan Vázquez [:soymos]]

Just to make it clear for me, so I install GLES3 and Mesa 22.2.4 from debian testing, then snap latest/edge 109.0a1 and then enable gfx.webrender.all to true?

Comment 29

[Darkspirit]

(In reply to Allan Vázquez [:soymos] from comment #28)

Just to make it clear for me, so I install GLES3 and Mesa 22.2.4 from debian testing, then snap latest/edge 109.0a1 and then enable gfx.webrender.all to true?

• Use Raspberry Pi 4 or better for GLES3 support.
• Use a modern distribution that has Mesa 22.2.4. Otherwise you need to build latest Mesa manually.
  If I understand correctly from my testing, you can't install the Mesa packages from Debian Testing on the regular Raspberry Pi OS (debian bullseye) anymore because now they depend on newer libc package, etc.
  I manually&painfully upgraded my 64-bit Raspberry Pi OS to Debian Testing. I would rather recommend https://ubuntu.com/download/raspberry-pi.
• If you open about:support in your address bar, Mesa version should be 22.2.4 and "Compositing" should be "WebRender".
  (gfx.webrender.all is a pref to force-enable hardware rendering on Mesa versions below 22.2.4, but then you would see wrong colors in YouTube videos or worse.)
• a) Try latest/edge 109a1 from Snap (if it works).
  or
  b) Mozilla doesn't offer official (mozilla-central) Linux Nightly builds yet (bug 1677963).
  But there are Linux arm64 Nightly builds without updater that are built in autoland CI (https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=success%2Crunnable&tier=2&job_type_name=build-linux64-aarch64%2Fopt > green "B" > Artifacts > target.tar.bz2).

Comment 30

[Allan Vázquez [:soymos]]

Wow thank you for explaining everything to me, now I see why this has been evolving slowly. I investigated a little bit ubuntu, and think that for now the most simple good option works for me, that is the reason for wanting firefox in the first place. Neither I can afford the pain of switching the entire system to debian testing, I am working to mount a small basic programming school that needs the stability. So I will need to wait, thank you all for the good work.

Comment 32

[Dave Jones]

My apologies for the late reply to this ticket; here's a quick update on the current situation on Ubuntu:

It appears the required fixes are in mesa 22.2.4. The version of mesa in ubuntu jammy (22.04) has recently been updated to 22.2.5 (and thus should contain the required fixes). Unfortunately, the snap version of firefox is currently based on Core 20 (ubuntu focal, 20.04) which isn't sufficiently recent to contain the required fixes. An experimental channel of the snap (latest/candidate/core22) has been created to contain builds based on Core 22 (based on ubuntu jammy, 22.04) which should be able to test the fix. Unfortunately, we're currently having issues building that branch on arm64 so it's not currently accessible. I'll try to remember to update this ticket if/when that channel gets fixed.