Firefox 94 To Start Using EGL On Linux - Better Performance, Lower Power Use

[pal666]

I can't swap "rsync (other flags) -l", which copies symlinks as symlinks for "rsync (other flags) -L", which copies symlinks as referent files and directories because I have lots of other symlinks I would want copied as symlinks.

you can use bind mounts instead of symlinks

[Lennie]

Is WebGPU a good idea for normal users? I myself disable even WebAssembly and WebGL support.

WebGPU, WebAssembly and WebGL are just APIs website can use to build webapps, disabling them does nothing for performance of your browser*. It would be like disabling OpenGL on your computer, it means certain games will not run anymore because they use that API to make their games run.

* Unless you are blocking a webpage from using it which uses it in a way you don't use and thus making it faster to load that way. For example if you disable Javascript and the webpage loads faster because ads can't load anymore or something similar.

[Michael_S]

you can use bind mounts instead of symlinks

Thank you again. I learned something new.

[blackshard]

So how does that increase performance?

Actually I don't know the technical details on what's under the cover.
EGL is a relatively recent API made to fit modern needs.

Probably there is the chance for a smoother interoperability among parties, with reduced memory block copies and more resource sharing.
Imagine, for example, if you need to play a video in a browser: copying every frame from video memory to browser memory kills performance, letting the browser draw directly accessing the frame memory is better, but letting the browser control a GPU surface that draws the frame content without moving data at all is even better.

[smitty3268]

Actually I don't know the technical details on what's under the cover.
EGL is a relatively recent API made to fit modern needs.

I don't think EGL by itself is inherently faster. The main difference is that EGL is designed to be cross-platform, while GLX is tied directly to X.

I believe the main reason that the EGL backend might be faster is that it's the newer, more maintained platform. New code is generally written with EGL in mind first, then possibly ported over to GLX later on if there's time to do so, and if that code isn't quite optimal nobody really has the time to fix it up. So it's just a matter of priorities.

[arQon]

This is one step forward towards hardware video acceleration being enabled by default. Right now you need both launching FF with MOZ_X11_EGL=1 and activate VA-API on the about:config tab. With 94 only the VA-API step will be necessary.

Bit late to the comments here, but you can also force EGL support via about:config and avoid needing the env var.

I haven't yet seen FF fail to trip over itself and choke when using EGL, and it also introduces "oops" crashes from Crunchyroll's video player every 10-20 minutes that have never happened in multiple years with EGL disabled. (Though that's potentially VAAPI, since obv that isn't an option without EGL).

So IME it's still pretty badly broken - but now that it's the default, it'll probably get sorted out in another year or so. (Based on how long it's taken so far to fix the VAAPI bug they introduced early this year, 3 months after FINALLY starting to support HW accel for video decode... sigh...)

[M@GOid]

Bit late to the comments here, but you can also force EGL support via about:config and avoid needing the env var.

I haven't yet seen FF fail to trip over itself and choke when using EGL, and it also introduces "oops" crashes from Crunchyroll's video player every 10-20 minutes that have never happened in multiple years with EGL disabled. (Though that's potentially VAAPI, since obv that isn't an option without EGL).

So IME it's still pretty badly broken - but now that it's the default, it'll probably get sorted out in another year or so. (Based on how long it's taken so far to fix the VAAPI bug they introduced early this year, 3 months after FINALLY starting to support HW accel for video decode... sigh...)

I watch YouTube and Netflix frequently, but both work just fine on a desktop RX 550 and in a old Intel Ivy Bridge laptop. Just to check, I watched a 24min anime on Crunchyroll and it went fine. All with EGL and VA-API, of course.

But I had stumbled upon some unsupported AMD APU, can't remember witch one exactly now, but it just didn't do the acceleration, don't remember crashes.

What distro and CPU/GPU/APU you use?

[arQon]

Just to check, I watched a 24min anime on Crunchyroll and it went fine. All with EGL and VA-API, of course.

Yep. Sometimes it's fine, but sometimes it all falls apart every few minutes. Based on similar experiences with the Pi4 and its custom Chrome build (also supporting HW decode) it seems almost entirely dependent on the exact bitstream: on the Pi, every time a particular cut was reused in one show, the player fell over.

> What distro and CPU/GPU/APU you use?

The HTPC that I watch most stuff on is a crappy Atom box (Baytrail). Interestingly, it does FAR better (performance-wise) with (h264) YouTube than whatever bastardised mess CR is using, which appears to take exactly as much as CPU as before. That suggests to me that the problems with CR are the result of issues with GBM/EGL explicitly rather than VAAPI, as the HTPC doesn't have HW support for VP9 or whatever it is that CR is using.

The HTPC is actually on 93 still, as I haven't gotten round to updating it for several weeks, but it's been forcing EGL support for a couple of months now.

It's interesting (to me, at least :P) that both the Atom (on FF) and the Pi (on Chrome), with very different underlying architectures, exhibit such very similar problems.

I'll update to 94 sometime in the next few days, but ATM we already know that VAAPI on Intel is basically broken in FF, so I'm expecting the crashes to continue for at least a few more months until the owner of that bug (who seems to be the only person actually advancing VAAPI in FF) gets round to looking at it. That's already taken 9 months (after it only working for 2-3 months after finally being implemented at all, years late) so I think it's fair to say that working video acceleration *on Linux* is a long way from being a priority for FF. (Understandable, but irritating).