Since I just got my Reform working again I’d figure I’d add to this with my current Firefox setup after I’d upgraded debian again. This is using the WebRenderer (Software) fallback as the hardware renderer fails to launch on here. I believe that’s due to the older OpenGL ES support of the etnaviv driver, or some other bug there. Honestly it’s still quite usable personally, but you do notice slowdowns when using some overly heavy web apps like Discord or the like.
im8mq: 0.813 ± 0.023
Actually, I found one more up to date, its called betterfox. And yes its also at github. Just a heads up.
This is better for newer firefox. Or you could use mullvad too I suppose. That’s a better firefox fork than waterfox or librewolf.
With RK3588 Pocket Reform + Firefox 138/139, I found some sites, such as MotionMark and RP2040 datasheet are unusually slow and laggy.
After some investigations, the bottleneck was turned out to be texture format conversions in Mesa.
I managed to workaround this by applying a small patch to Mesa.
With this patch, MotionMark score drastically jumped up from 19.27 to 115.66!
As I tested on Gentoo, I wonder if the same thing happens on Debian. Could someone confirm this? With that, I would report this issue to the upstream.
Below are commands I used to build Mesa:
# latest hash 0d3ffd8275087bc7f5b872303338ab10dcf287d9
git clone --depth=1 https://gitlab.freedesktop.org/mesa/mesa.git
cd mesa
curl -L 'https://raw.githubusercontent.com/mojyack/etc-portage/refs/heads/musl/patches/media-libs/mesa/panfrost-enable-blit.patch' | patch -p1
meson setup build --buildtype=debugoptimized --prefix=/tmp/rootfs -Dgallium-drivers=panfrost -Dplatforms=wayland -Dglx=disabled
ninja -C build install
LD_LIBRARY_PATH=/tmp/rootfs/lib firefox
I get a score on RK3588 Pocket Reform of 224.27@30fps which is double of what you get at 60 fps which I guess suggests that there is no problem in Debian unstable to begin with? This is with firefox 139.0.1 and mesa 25.0.7. What is your mesa version?
Thank you for reporting. That’s surprising.
I tested with mesa 25.0.5 and current HEAD.
How is the score at 60 FPS? And note that my scores are of MotionMark 1.3, not MotionMark 1.3.1.
I measured 1.3.1@30fps scores on normal debian and patched gentoo.
Here are results: 217.72 vs 686.90
Found an another way to workaround the issue.
Here is a patch.
I can’t say for sure since MotionMark scores seem to be unstable, but this method looks to perform better.
I’m excited that you’re looking into this and especially that you’re finding causes for the slowness. Bad perf of Firefox vs Chromium was really bugging me, so thanks for this. Can you tell me where the BGRA patch idea/source comes from? Also, the blit patch link is 404, what was it about?
Can you tell me where the BGRA patch idea/source comes from?
Here’s the rough process of how I created that patch:
mesa_format_convert functionglTexSubImage2D to upload BGRA image to RGBA texture, causing format conversion.GL_EXT_texture_format_BGRA8888 while amdgpu doesn’t. I tried to force firefox to use RGBA texture format by supports_texture_storage_with_gles_bgra = false in here_mesa_choose_texture_format(..., internalFormat=GL_BGRA8_EXT,...) here returning PIPE_FORMAT_R8G8B8A8_UNORM rather than PIPE_FORMAT_B8G8R8A8_UNORM.Also, the blit patch link is 404, what was it about?
Here.
Sorry, I’ve removed that patch from my tree.
I would like to give you more hearts for your last post. I very much wondered how you approached figuring this out and your detailed explanation (even including screenshots!) made me learn a lot. Thank you!
Thanks for the great explanation! I’ve had similar issues for GTK3 apps in GNOME where there were a lot of weird texture format conversions. It wasn’t clear though that this could be fixed in mesa. I tried your patch and indeed Firefox is much faster now, which is awesome, because I really didn’t enjoy being locked into Chromium for performance reasons. I’ve passed this on to the relevant mesa devs and they confirmed this is a “great find” and I guess they’ll do something to fix it.
A tiny update: gtk3 “Fishbowl” demo/benchmark is not fixed by this, so that’s a different, but maybe related problem. If you’re curious, you can see it if you open gtk3-demo and go to Benchmark->Fishbowl and make the window fullscreen. FPS will suffer a lot. The same benchmark in gtk4-demo doesn’t have this issue.
I tried your patch and indeed Firefox is much faster now, which is awesome, because I really didn’t enjoy being locked into Chromium for performance reasons.
That’s a good news!
I’ve passed this on to the relevant mesa devs and they confirmed this is a “great find” and I guess they’ll do something to fix it.
Thank you for taking action.
If you’re curious, you can see it if you open
gtk3-demoand go to Benchmark->Fishbowl and make the window fullscreen.
Ok I’ll look into that.
I’ve tried both of gtk3-demo and gtk4-demo, but couldn’t find such an major FPS suffering.
The performance difference between them shown above is understandable,
since GTK4 utilizes OpenGL to render widgets while GTK3 doesn’t.
@mojyack I prepared mesa built with your patch in this MR: wip: apply mojyack-panfrost-enable-blit.patch (!117) · Merge requests · Reform / reform-debian-packages · GitLab Please tell me if you’d like to be attributed differently.
Anybody else can now put this into their apt’s sources.list to try this out:
deb [trusted=yes arch=arm64] https://source.mnt.re/reform/reform-debian-packages/-/jobs/11212/artifacts/raw/repo reform main
Thanks a lot for the patch, it looks great. Could you please submit this to Mesa as a merge request?
From this post by minute, I think it will be fixed without doing so.
But of course I will if I have to.
We’re happy to take the patch and get it pushed through for you, but I think it’s always nice if the person who did the actual work gets their name clearly recognised on the merge request etc!
I’m preparing a MR.
But before submitting it, I want to test it with another GPU.
Please wait a while.
Just created a MR.