Firefox Nightly Tries For VA-API Video Acceleration For Mesa Users

[birdie]

In my test, I didn't resize windows, so i had excluded compositing. Full disclosure: I ran my test again with both radeontop and htop and detected CPU and GPU load.

CPU activity is inevitable, what matters is how responsive, fast and fluid everything is. In my experience UI in Windows and MacOS is much better in all three aspects. Everything just "feels" faster.

Are those were questions? Well, well...

And this whole off-topic discussion began here:

Those were my earlier posts in the topic. For several pages now I've been asking for a simple test, please. If you can prove me wrong, my bad, I will apologize promptly. I'm not afraid of admitting I was wrong - I've done that multiple times.

[s_j_newbury]

CPU activity is inevitable, what matters is how responsive, fast and fluid everything is. In my experience UI in Windows and MacOS is much better in all three aspects. Everything just "feels" faster.



Those were my earlier posts in the topic. For several pages now I've been asking for a simple test, please. If you can prove me wrong, my bad, I will apologize promptly. I'm not afraid of admitting I was wrong - I've done that multiple times.

On modern hardware, even if it was only using CPU it surprises me your UI rendering isn't keeping up with your display update frequency. My main machine, which is really old(!) (AMD FX9370 + RX470) manages to render desktop UIs at 60Hz without any issues. If that isn't happening something is definitely wrong. Any "feeling" faster is more likely due to animation duration than rendering performance.

[Ermine]

CPU activity is inevitable, what matters is how responsive, fast and fluid everything is. In my experience UI in Windows and MacOS is much better in all three aspects. Everything just "feels" faster.

Meanwhile, I tried resizing test on Windows with QBittorrent (Qt 5), Windows Explorer and Settings app. According to Task Manager, these apps generated CPU activity comparable to that on Linux. Most of GPU activity here was generated by dwm.exe. (By the way, Windows can show per-process GPU usage and this is its strong side, but this is not the point now.)

And in my experience, Plasma is so smooth that I felt like I have 120Hz monitor and not 60Hz. And on my weaker device, Windows can sluggish (as well as Plasma - due to Wayland's frame perfection). But this is all experience, not the bare numbers.

So my statement is: I can detect rendering-related GPU activity, thus Qt uses GPU for rendering on Linux, apparently to the same extent Windows apps do use it.

[Quackdoc]

Because:
1. Relying on a single developer that who knows for how long he will develop this thing, isn't a good idea.
2. It seems to be an early wip project, so it doesn't support all codecs and has a lot of bugs. There are also other limitations according to its readme page.

my point is that vaapi is not exclusive to mesa. like I said, there is also v4l2 support.

What implementation? That unofficial translation layer from vaapi to nvenc? Cause that's the only one I heard about.
Vaapi relies on the dri/drm infrastructure, which Nvidia doesn't use in its drivers, so that's why it can't support it.

it's a VAAPI backend that uses nvdec. vaapi as most people think of consists of two parts , VAAPI itself and libva (not sure how the nvdec vaapi works), im pretty sure vaapi itself does not rely on dri or drm. libva might? I have no idea. I don't believe it did, I heard that it explicitly did not rely on them. but that could have been wrong.

[user1]

my point is that vaapi is not exclusive to mesa. like I said, there is also v4l2 support.

I didn't know what is v4l2, but I've read a bit about it and it's apparently some driver collection for real time video capture. I mean it probably can utilize vaapi, but then I don't understand how is it relevant in this discussion, when vaapi itself still depends on the device GPU drivers?

[sinepgib]

Are you using a Pentium 4? One of the main issue why GPU based video en/decoding is such a slow starter on Linux is that it became really unnecessary in the meantime for Workstations. Video Rendering with a CPU based pipeline just causes such minimal CPU usage on anything from the last 10 years that there simply is not much demand and low demand means low motivation.

But then again one very often repeated use case for Linux is to give life to older and lower end computers. But of course, that's not the paying customers, so that logically becomes the responsibility of the community. And the community is currently more whiners than doers, so there's that.

So yeah sorry for the reality check, but GPU acceleration story in Linux is complete and utter shambles and its actually personally my last straw that convinced me to get a macbook pro for work because I was sick of tired of having stuttering in video conferencing because it was using the CPU (and since I am not so young anymore, I don't really have the time to fuk around with all of the flags/settings/GPU decoder APIs with browser to get it to work).

While I agree, I'd like to note in many aspects the GPU acceleration in Linux improved leaps in the last few years.
And regarding the MacBooks, my work makes me use one, the M1 works wonders with Meets, but the Intel one is absolutely terrible, it feels the computer will take off flight because of how much the fans spin. I'm pretty sure specifically for that it's even worse than Linux. Using Firefox tho, it's probably just shit support from them rather than something inherent to the Mac.

I know, I hate snaps too. (Btw, the faster updates via snap argument is not really valid because the update from Firefox snap 99 to 100 was pretty slow).
I was talking about the regular Firefox packages preinstalled in most other distros. Btw, if you use the distro agnostic tarball that can be downloaded from Firefox website, it has the fastest startup time. Not a big difference compared to Firefox via package manager, but still a bit noticeable.

We can't ignore that Ubuntu is one of the most popular distros tho. So however they do it will impact the experience of a big portion of Linux users. Regarding the distro agnostic tarball, you mean the regular build your own of FLOSS or an actual binary? I don't expect most people to deal with that, so it'd be unacceptable if we intend Linux to have a relevant market share in desktops.

Is GNOME fully GPU-accelerated (whatever that means) because they have enough manpower (funded by RedHat to some extent) to make it work, or because interfaces (Mesa or whatever) are adequate and everyone can make their desktop GPU-accelerated without much pain?

I think the issue is not the interfaces themselves for that but how well is the driver support. While optimally some devices may have some specific hardware that may be better than the actual 3D acceleration part of the GPU for the 2D acceleration the desktop can benefit from (I heard that's no longer the case for years tho), OpenGL is probably good enough in most cases. I mean, all a desktop should really mean, with no dumb eye candy, is probably some blitting and having surfaces for their windows, it's nowhere as complex in terms of needed APIs as rendering a game.

Doesn't change the fact that DEs don't "support" specific GPUs but call generic APIs to make use of them.
It's utter nonsense to believe that Windows would have any magic GPU acceleration that would make it run better than e.g. Plasma Wayland on lowend devices. The opposite applies, Firefox WR Windows is much more painful to use than WR Plasma Wayland on e.g. slow Gemini Lake SoC. Same goes for Chromium. People should stop whining without having the slightest clue how well optimized current Linux desktop can be...

Oh, and on such devices, VAAPI video playback in Firefox btw. is much smoother than Firefox Windows D3D11VA...

Oh, yeah. I was just discussing that they don't have _anything_ to do with GPU acceleration. Of course they'd use standard APIs just as any other OS does (Windows uses several APIs for the UIs which probably end up creating a command stream of Direct3D).

About what is supported... Even tho DEs are not the place, as long as it's there that it manifests it doesn't matter which component is supposed to support said API but the fact some cards aren't properly supported, namely most small vendors and depending on a few factors you could consider nvidia properly supported or not in DEs. We pretty much have decent support for AMD and Intel and some reverse engineered support for some VideoCore devices for which I have no idea of how good the support is, but I'd assume good enough for desktop acceleration.

Regarding people complaining... Well, there are only three reasonable options: either you don't complain about what you get for free (clear exception being paying customers of commercial distros), you contribute (money or time) or you simply don't use it if it doesn't suit your needs. Now, describing what's the (perceived) state of something and complaining about it are two different things, and in any case, given the limited time and money people have, complaining rights may be extended if you are active in another component, as you're already doing what you can to improve the state of FLOSS.

[user1]

Regarding the distro agnostic tarball, you mean the regular build your own of FLOSS or an actual binary? I don't expect most people to deal with that, so it'd be unacceptable if we intend Linux to have a relevant market share in desktops.

I meant the compiled binary that can be downloaded here. I've also seen other people that wanted to avoid Firefox Snap on Ubuntu, were talking about it. You can extract it anywhere in your home directory and just double click on the "firefox" executable to open it.

[Quackdoc]

I didn't know what is v4l2, but I've read a bit about it and it's apparently some driver collection for real time video capture. I mean it probably can utilize vaapi, but then I don't understand how is it relevant in this discussion, when vaapi itself still depends on the device GPU drivers?

v4l2 is just a generic interface for video, most arm devices don't even have the video block on the gpu. in fact on most arm devices, video blocks are entirely separate from gpus. things like rpi use v4l2 for video acceleration. instead of using the gallium drivers like desktop gpus do.

[oleid]

OMG. Year 2022 and Linux still renders UI in software mode.

No, not software. But what you seem to realize it's that hardware rendering is not necessarily fast

[mdedetrich]

While I agree, I'd like to note in many aspects the GPU acceleration in Linux improved leaps in the last few years.
And regarding the MacBooks, my work makes me use one, the M1 works wonders with Meets, but the Intel one is absolutely terrible, it feels the computer will take off flight because of how much the fans spin. I'm pretty sure specifically for that it's even worse than Linux. Using Firefox tho, it's probably just shit support from them rather than something inherent to the Mac.

I have an Intel based based Mac thats 7 years old and have the exact same issue with the fans. Its one of the reasons I moved away from the Mac. From what I heard, this is largely a result of the Intel laptop CPU's being terrible for a like 6 years because Intel got complacent and was stuck at 14nm for a decade and because of that it became ridiculously hard to cool laptops if you wanted decent performance.

This is one of the things that really pissed off Apple terrible and one of the main reasons why they started building their own chips for laptops.