Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by treba View Post

    Encoding and decoding are two quite different things. I'm super happy to see decoding finally working properly (and being done in the sandboxed RDD process).
    I don't expect hardware encoding coming anytime soon, given how unreliable it still appears to be - and the difficult legal issues. Here's the bugzilla entry for it, in case somebody is interested: https://bugzilla.mozilla.org/show_bug.cgi?id=1658900

    It will likely become easier once all sharing (both camera and desktop/windows) is done via dmabuf. For cameras that will be the case once Pipewire is used in webrtc. There's a pending MR here: https://chromium-review.googlesource.../src/+/3308882 But even with that there's still a bunch of stuff missing. However, using Pipewire will have the additional benefit of using libcamera under the hood, allowing a bunch of non-v4l2 cameras to be used, which is increasingly common in tablets etc.
    Let's set legal issues aside for now. I need to do some research on it to give sensible answer (at the first glance, why intel does something questionable from the legal point of view? They definitely don't want to get punished for that).

    On the technical point of view, so we needed dmabuf and pipewire to make hardware-accelerated encoding a reality?

    Given the age of VA-API, why is it still hard to integrate encoding? As it happens often in Linux world, kernel interfaces were deemed not expressive enough, so they were extended (with dmabuf, I suppose). Ah, and also we need pipewire. This makes me question VA-API interface. You know, one must question interfaces in order to create good software.
    Last edited by Ermine; 03 June 2022, 01:43 AM. Reason: Some additional thoughts on this topic

    Comment


    • #32
      Originally posted by oleid View Post

      Use GNOME. The desktop is GPU accelerated and since GTK4 apps are as well.
      Not protecting birdie, but you are missing the point. birdie questions state of GPU acceleration in Linux desktop per se. He did not ask for advice on software.

      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?

      Comment


      • #33
        Originally posted by guspitts View Post
        Oh yes, please, make it happen. I am still on FF97 for that reason.
        If that's true, you should upgrade immediately. Firefox 91 is the Extended Support Release (ESR). You are incredibly vulnerable surfing the internet with FF97, because it doesn't get any security updates. That is not worth having hardware acceleration. You could rather try to disable the RDD sandbox in order to get it running in the current version. That's also insecure, but not as much as running FF97.

        Comment


        • #34
          Originally posted by user1 View Post

          And do you think Chrome / Chromium based browsers are better than this? I think they're all much worse in supporting Linux. Their VAAPI support is much more abysmal, their startup time is much slower on Linux than on Windows (at least it seems like Mozilla optimized Firefox startup time on Linux within the last year, so now it's more or less comparable to Windows). And Wayland support is also more mature in Firefox.
          Not really, on Ubuntu FF now comes from a snap produced by Mozilla with 3x larger startup time (I've seen 15 sec. startup times). The excuse being snap can be updated faster. I had to remove and install FF from a ppa to resolve this.

          Comment


          • #35
            Originally posted by oleid View Post

            Use GNOME. The desktop is GPU accelerated and since GTK4 apps are as well.
            I'm not sure GTK or Qt under Linux accelerate any drawing operations. Window management is accelerated when using compositing - that's it.

            Comment


            • #36
              Originally posted by aufkrawall View Post
              Something tells me this isn't entirely accurate...


              DEs don't support any GPUs at all because it's not their job.



              Most UIs in Windows are basic GDI stuff that are hardly GPU accelerated at all.

              Stop believing in unicorns.
              It's still better than in Linux where all in-app drawing is done by the CPU if I'm not mistaken.

              Windows 7 includes GDI hardware acceleration for blitting operations in the Windows Display Driver Model v1.1. This improves GDI performance and allows DWM to use local video memory for compositing, thereby reducing system memory footprint and increasing the performance of graphics operations. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. GDI+ continues to rely on software rendering in Windows 7.[9]

              Comment


              • #37
                Originally posted by ferry View Post

                Not really, on Ubuntu FF now comes from a snap produced by Mozilla with 3x larger startup time (I've seen 15 sec. startup times). The excuse being snap can be updated faster. I had to remove and install FF from a ppa to resolve this.
                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.

                Comment


                • #38
                  Originally posted by sinepgib View Post
                  Compositing windows is the main task of window managers, which are quite the central part of being a desktop environment. Guess what's very efficient and nice when done by the GPU...
                  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...

                  Comment


                  • #39
                    Originally posted by birdie View Post

                    It's still better than in Linux where all in-app drawing is done by the CPU if I'm not mistaken.

                    Windows 7 includes GDI hardware acceleration for blitting operations in the Windows Display Driver Model v1.1. This improves GDI performance and allows DWM to use local video memory for compositing, thereby reducing system memory footprint and increasing the performance of graphics operations. Most primitive GDI operations are still not hardware-accelerated, unlike Direct2D. GDI+ continues to rely on software rendering in Windows 7.[9]
                    Not all.
                    Qt 5 and GTK 3 yes, but I think Qt Quick (Qt 5 and 6) and GTK 4 do use the graphics card to render.

                    Comment


                    • #40
                      Originally posted by tildearrow View Post

                      Not all.
                      Qt 5 and GTK 3 yes, but I think Qt Quick (Qt 5 and 6) and GTK 4 do use the graphics card to render.
                      I wanna see the actual proofs of that. A blog post made by someone who's in the topic will suffice. I remember X11 drawing primitives were GPU accelerated but those haven't been used by anything in Linux for more than a decade.

                      Comment

                      Working...
                      X