Closed Bug 1663285 Opened 4 years ago Closed 1 year ago

poor performance in firefox with webrender on raspberry pi4

Categories

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

Firefox 82
ARM64
Linux
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox82 --- disabled

People

(Reporter: sk.griffinix, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: nightly-community, perf)

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

Also check bug 1661359

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

Blocks: raspi, wr-perf
OS: Unspecified → Linux
Hardware: Unspecified → ARM64
Severity: -- → S3

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

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.

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

Flags: needinfo?(vinceying113)
Blocks: wr-low-end-perf
No longer blocks: wr-perf

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

Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Flags: needinfo?(vinceying113) → needinfo?(gwatson)
Flags: needinfo?(gwatson)
Blocks: snap

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).

Dave, what prefs did you set?

Flags: needinfo?(dave)

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!)

Flags: needinfo?(dave)

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?

Flags: needinfo?(dave)

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?

Flags: needinfo?(sk.griffinix)

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

Flags: needinfo?(sk.griffinix) → needinfo?(vinceying113)

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

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.

Flags: needinfo?(vinceying113) → needinfo?(gwatson)
Flags: needinfo?(gwatson)

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

Flags: needinfo?(lissyx+mozillians)

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

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

Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(lissyx+mozillians)

Do you mean a modified version of firefox snap Alexandre LISSY [: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.

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?

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

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.

Priority: -- → P4

The fix should in the current dev version of Ubuntu

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?

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.

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

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?

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

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.

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.

Flags: needinfo?(dave)
Status: NEW → RESOLVED
Closed: 1 year ago
Depends on: 1784327, 1783924
Flags: needinfo?(lissyx+mozillians)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.