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

  • Originally posted by Ermine View Post

    Given that 1) FFMEG's VA-API support is partial (while NVENC/NVDEC support is complete) (https://trac.ffmpeg.org/wiki/HWAccelIntro), 2) OBS Studio hides VA-API encoding option in advanced options (and you can select NVENC right away) 3) some distros (checked Ubuntu and Arch) don't even enable FFMEG VA-API via --enable-vaapi configure flag, I'm inclined to think that VA-API is not that good.
    Furthermore, the VA-API implementation in the Radeon driver is less complete than the Intel one (e,g, VideoProc isn't working properly (wrong scaling and hangs in Mesa 19.1+), asking for HEVC encode at 1920×1080 returns 1920×1088, no encoding speed parameter (yet?) and no global header support (so no Matroska for example)).

    Comment


    • Originally posted by birdie View Post

      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.
      I don't think this will be enough, but:

      Qt Quick (you can see MangoHUD visible on the window)



      non-Quick Qt (no MangoHUD visible)



      The sad part is that only few applications use Qt Quick (parts of KDE System Settings and Discover do for example), which means the rest is still CPU based :<

      Comment


      • Originally posted by tildearrow View Post

        I don't think this will be enough, but:

        Qt Quick (you can see MangoHUD visible on the window)

        The sad part is that only few applications use Qt Quick (parts of KDE System Settings and Discover do for example), which means the rest is still CPU based :<
        Composition has been GPU accelerated for years, tilde. I'm asking about how applications are rendered on the inside.

        Comment


        • Originally posted by tildearrow View Post

          I think it's more like Mozilla not caring about Linux consumers because the userbase is small when compared to Windows.
          Firefox developer here, in one of the teams who laid out a lot of the plumbing needed to make this happen. We very much care but getting this stuff to work on Linux proved to be exceptionally complex: Linux support requires this stuff to work on the broadest set of kernels, Mesa versions, glibc versions, graphics hardware and distros. That's hard. It's impossible to test all the possible configurations our users are on, which is one of the biggest reasons why Linux support tends to move more slowly. There's always a LTS distro we still need to support and we can't ship a broken Firefox to the users that are still on it. Additionally video decoding is a complex beast with regards to the sandbox and thus indirectly IPC. There's been a lot of work around how different processes would share buffers and resources and how to handle the system calls coming from within the video decoders.

          To give you an idea of the complexity of this work just check out this bug which I helped figure out a couple of weeks ago. We hit crashes related to sandboxing NUMA controls that were coming from a major distro but not using its standard packages... for video decoding. This stuff is hard and takes a lot of time in order for it to be both stable and secure.

          Comment


          • Originally posted by tildearrow View Post

            [B]Nope, I have not said or thought this.
            I know, I just wanted to point out that when comparing Firefox on Linux to Chromium browsers on Linux, it's miles better. Also, I would say Mozilla is sometimes pretty slow in fixing some bugs. For example, Firefox 98 introduced a bug that caused stuttery scrolling in some pages. This bug affected all platforms and was fixed only in Firefox 100. So I don't think this current vaapi bug took so long to fix because "Mozilla doesn't care about Linux consumers". And I think we all know that video decoding support is generally a mess on Linux for various reasons, some of them discussed in this thread, so why blame specifically Mozilla for this?
            Last edited by user1; 04 June 2022, 05:10 AM.

            Comment


            • Originally posted by Ermine View Post

              I know what GPU acceleration mean. Radeontop in my tests shows shader-related activity, not just pushing buffers to the screen.
              Ah okay, nvm then

              Comment


              • I suspect you simply have too much spare time complaining about stuff that doesn't matter much, see also implicit vs. explicit rendering discussion.
                Firefox Wayland GPU performance is fine vs. Windows, as is Plasma Wayland desktop performance. VAAPI decoding efficiency is fine vs. Windows D3D11VA. Do you even test and use stuff, or skip directly to useless complaints?
                Btw. basic drawing operations with few shapes and lines are already insanely fast on any CPU, kind of proves my point...

                Comment


                • Originally posted by crystall View Post
                  We hit crashes related to sandboxing NUMA controls that were coming from a major distro but not using its standard packages... for video decoding.
                  Wait, there's people playing videos on Firefox on NUMA machines? What absolute nonsense people do sometimes...

                  Comment


                  • Originally posted by aufkrawall View Post
                    Btw. basic drawing operations with few shapes and lines are already insanely fast on any CPU, kind of proves my point...
                    Being fast is not always the only thing that matters. Consider this:
                    - You're on mobile, battery life matters. A LOT.
                    - You have your GPU active (you're compositing after all).
                    - This activity would mean minimal load for a GPU, which means it's unlikely to overclock, so it won't drain more energy.
                    - This activity, while fast on fast CPUs, means greater load for them, as they're not specialized, so it'll likely keep them from going into lower power states.
                    - Your battery drains faster.

                    And that's something I factually noticed over the years on dual boot computers: battery tends to last longer on laptops when running Windows, at least in my experience.
                    Acceleration is not only about speed, it's also about using specialized hardware to achieve better power efficiency.

                    Comment


                    • Originally posted by sinepgib View Post
                      And that's something I factually noticed over the years on dual boot computers:
                      Well, then your observations probably are ancient and may not apply anymore by a large margin.
                      I got dualboot Windows & Arch on that Gemini Lake 2C CPU notebook and even with slow conservative CPU clock governor and strict 6W TDP enforced on Linux vs. 12W on Windows, performance while browsing the web, files, watching videos etc. is just massively better with Plasma Wayland vs. Windows 10/11.

                      Sorry, but if you think there really would be a major performance drawback in real life due to differences in GPU acceleration of Linux vs. Windows, you're simply clueless. I basically got the shittiest "modern" SoC out there and the results just speak for themselves. You're chasing ghosts, that's all I got left to say. I can't take this seriously, sorry.
                      Last edited by aufkrawall; 04 June 2022, 06:47 PM.

                      Comment

                      Working...
                      X