
Firefox on Linux have suffered by poor WebGL performance for long, long time. It was given by missing general acceleration on Linux as there are always broken gfx drivers on X11, various hacks and different standards, closed source drivers and so on. Long story short – to do gfx acceleration seriously on Linux have been PITA. For instance Chrome (which supports gfx acceleration on Linux/X11) shows long list of active exceptions and workarounds listen at chrome://gpu/ page.
It’s also reason why Firefox never enabled it by default although it also implements gfx acceleration – Mozilla does not have resources to spend too much time on every broken gfx card / driver.
Fortunately situation was changed with Wayland. Working gfx acceleration is a sort of prerequisite to even start a decent Wayland compositor like Mutter or Plasma so when Firefox is launched on Wayland we can pretty much expect working GL environment. Also dmabuf is widely supported by Wayland compositor so we finally have all pieces together to build fully accelerated browser on Linux which is equal to its Windows siblings.
Firefox supports two acceleration modes – WebRender and GL compositor. WebRender is the new one and it’s superior in web content rendering. GL compositor is the former one, less advanced but it’s still faster for some scenarios where bits are heavily shifted from one side to another one – video playback and WebGL.
Both WebRender and GL compositor have implemented dmabuf back end which means textures used by WebRender/GL compositor can be created directly at GPU and shared without copy among compositor / GPU browser processes. Such GPU memory can be in the same time mapped as EGL framebuffer so we can render WebGL frames directly to GPU memory, handle them from webgl process to chrome process and render it as a texture to a web page.
All those pieces are tied together in recent nightly where we finally have full WebGL support on Wayland and it will be shipped as Firefox 75. If you run Fedora/Gnome you can try it by yourself. Just grab latest nightly from Mozilla, enable HW acceleration, set widget.wayland-dmabuf-webgl.enabled to true at about:config, restart browser and open your favorite WebGL application like maps.google.com or WebGL samples.
Is the config “widget.wayland-dmabuf-webgl.enabled” the only one necessary to enable this feature, or should WebRender be enabled as well?
LikeLike
You also need to enable GL compositor (by layers.acceleration.force-enabled) or WebRender (gfx.webrender.enabled and gfx.webrender.all). But WebRender it enabled by default on some nightly, you can check that at about:support page at “Compositor” field.
LikeLiked by 1 person
Just want to pass along a big thanks for your work on this!
LikeLike
Excellent news. I don’t understand how Wayland is so little used on Linux Oses.
LikeLike
Because not all desktop environments support Wayland, for example XFCE.
There’s also the problem of hardware support.
LikeLike
Hardware is not an issue. Wayland itself have no requirement on hardware, on other side, compositors implementing Wayland rely on OpenGL by their choice.
It’s great that we finally getting some fruits from Wayland development.
LikeLiked by 2 people
So, it’s a problem of development. Just gnome developers are integrating Wayland. The other ones stuck on legacy X11.
LikeLike
Does all this work with EGLStreams / the Nvidia binary blob?
LikeLiked by 1 person
> on Linux as there are always broken gfx drivers on X11, various hacks and different standards, closed source drivers and so on
Ehm… Is it really true? Though I personally haven’t been with GNU/Linux long enough, but a decode ago Dolphin developers praised all GNU/Linux drivers except the prorietary fglrx of AMD https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/ And Mesa devs are both responsive regarding regressions and have a great test-suite. Regarding fglrx, it has been discontinued and died in preference of Mesa.
So what you’re saying sounds very odd to me.
LikeLiked by 2 people
RedHat devs love to rewrite history
LikeLike
Well, it’s just a personal blog of one developer, and people happen to be wrong. I think it’s incorrect to generalize one developer opinion to that of a company. Red Hat in general are cool guys, because they are one of the major contributors to the Linux ecosystem. And Martin in particular is a great contributor that helped Linux version of Firefox a lot, so kudos to him either way.
LikeLike
What about the support of Nvidia drivers on Wayland? Is there any news?
LikeLike
Thanks for the great work!
One question: I assume FF 75 will get the features, but not the defaults? When does Firefox plan to flip various kinds of hardware acceleration “on” by default?
LikeLike
Yes, Firefox 75 will have it, more or less. Not sure when will be flipped on by default.
LikeLike
“You can verify that VA-API is enabled by running Firefox with MOZ_LOG=”PlatformDecoderModule:5″ env variable and check in the log output that VA-API is enabled and used.”
Where is this log located. I read the bugzilla post about enabling this but I can’t find any information about this magic log that will confirm if it is working.
LikeLike
You need to run firefox from terminal, so open command line and run:
MOZ_ENABLE_WAYLAND=1 MOZ_LOG=”PlatformDecoderModule:5″ ./firefox
LikeLike
Firefox 75.0 landed on Arch testing repo and i decided to give it a spin. The good news are that the hover/focus issues that plagued the previous versions on Wayland are gone. It seems in pretty good shape now to me.
The bad news are that the new dmabuf options that appeared in this version don’t seem to work for me. dmabuf-backend.enabled works fine since the previous version, dmabuf-webgl.enabled just makes WebGL Aquarium appear grey/not show anything on screen (it works fine, although slow, with the setting disabled), and all other dmabuf options (basic-compositor, vaapi, textures) make all the tabs crash as soon as i click on them. Sometimes even firefox itself crashes.
I am running Archlinux with the latest stable Gnome and Mesa, on an AMD R9 380 gpu. I don’t know if there is something wrong with the distro packages or with the driver, just wanted to share my experience. Still, i want to thank you for your excellent work! It means a lot to us all Linux users!
LikeLike
Thanks for your report, please test latest nightly. Firefox 75 is missing some important dmabuf fixes which needs to be backported by distros. I’m going to write a blogpost about it.
LikeLiked by 1 person
I tested the latest nightly 77.0a1 for a bit. Seems dmabuf-vaapi and dmabuf-webgl can be enabled now for me without crashing, though dmabuf-textures still crash every tab almost instantly if enabled. Didn’t find any toggle for dmabuf-backend so i suppose it was removed? Anyway playing videos with vaapi doesn’t crash now but i am not sure it uses hardware acceleration on my gpu. How can i be sure? i am getting this on terminal:
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
amdgpu: drmGetDevice2 failed.
As for webgl, in aquarium sample i am still getting a grey screen with this log:
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open amdgpu (search paths /usr/lib/dri)
failed to load driver: amdgpu
WebGL(0x7fb6d9681000)::LoseContext(0)
By the way when dmabuf-textures is enabled and tabs insta-crush i am getting similar failed to load messages plus i am getting a ton of these:
[GFX1-]: Failed to create DrawTarget, Type: 3 Size: Size(1680,33), Data: 0, Stride: 0
and these
###!!! [Parent][MessageChannel] Error: (msgtype=0x5A001C,name=PHttpChannel::Msg_DeleteSelf) Channel error: cannot send/recv
Perhaps something is missing from Archlinux packages? VAAPI and 3D accel work perfectly fine outside Firefox for me. Maybe something is not configured right? About:support has no issue finding my driver though
Active Yes
Description AMD Radeon (TM) R9 380 Series (TONGA, DRM 3.36.0, 5.6.3-zen1-1-zen, LLVM 9.0.1)
Vendor ID 0x1002
Device ID 0x6939
Driver Vendor mesa/radeonsi
Driver Version 20.0.4.0
RAM 2048
LikeLike
dmabuf-textures is useless and it’s here for testing purposes only. It’s actually removed from beta/release builds.
For the rest please file a bug at bugzilla.mozilla.org under Core/Graphics and CC me there, needs to be investigated.
Thanks.
LikeLike
I’m having the same issue. Was a bug created for this?
LikeLike
I’m not aware of anyone, please file it if you have this issue and cc me there.
Thanks.
LikeLike
I am late to the party but i tried the latest nightly this morning (with the intention of opening a bug report of none present) and everything now works as it should i think. No crashes, webgl is fast and stable, same with vaapi. Running with MOZ_LOG=”PlatformDecoderModule:5″ ./firefox does not seem to produce any message when running a video or executing a webgl sample, so i suppose this is a good thing. Any chance these fixes land with 76 stable? I tried finding a relevant bug report, to report that things now work fine, but i couldn’t find any, so i am telling you here.
Overall i fiddled around with many websites and it seems really fast and with no issues at all. I am impressed. Seems to me it won’t be long until you can enable these by default. Great job! Thank you!
LikeLiked by 1 person
I’m experiencing the grey screen of death issue too. It seems to be caused by an underlying Mesa bug, which will probably be fixed in the next version 20.0.8. Try again in a week or two? Relevant bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1634213
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2882
LikeLike
Update: the fix didn’t make it into Mesa 20.1.0, but is in 20.1.1, which should become available on Arch in about a week.
LikeLike
I’ll try to backport the fixes to Fedora Firefox 76 package, I don’t think Mozilla is going to uplift them. Other distros can take patches from Fedora or wait to 77.
LikeLike