Announcement

Collapse
No announcement yet.

Video Acceleration Takes The Backseat On Chrome For Linux

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

  • #16
    Originally posted by getaceres View Post
    Oh yes, let's blame Google
    Yes. Lets.

    Comment


    • #17
      I use the opensource radeon stack on my HD 6870 and am a heavy Google Chrome user with the GPU blacklist disabled (to enable hardware acceleration where possible). Everything runs fine. Obviously video decoding is not accelerated, I am only talking about the general usage.

      Comment


      • #18
        Originally posted by madjr View Post
        Anyway does chromeOS has acceleration of some kind ? I would think they would enable it at least for their own platform
        As of December, some Samsung Chromebooks had the following flags you could enable or switch to default behavior to try out experimental Chrome OS video acceleration.

        Enable the following:
        chrome://flags/#ignore-gpu-blacklist
        chrome://flags/#enable-experimental-canvas-features
        chrome://flags/#accelerated-filters
        chrome://flags/#enable-nacl

        Set the following as default:
        chrome://flags/#force-accelerated-composited-scrolling
        chrome://flags/#force-universal-accelerated-composited-scrolling

        Also, you could enable swap if it wasn't already to give it a bit of a boost:
        (Ctrl+Alt+T) and type "swap enable" and reboot

        There's some Chromebook Google groups posts describing these flags in greater detail. It was all experimental in December, but seems stable enough, and gives a better experience. There may be some additional video acceleration flags in the past couple of months - I haven't checked recently.

        Comment


        • #19
          Originally posted by getaceres View Post
          Oh yes, let's blame Google for being tired the mess which is the graphical stack of Linux nowadays. We have a graphic stack which was designed more than 30 years ago and to make it work with modern paradigms we patch it in every conceivable way. So taking apart DRI vs DRI2, XInput vs XInput2, Mesa vs Gallium3D, KMS and any other new patch above X limitations:
          Well, it's not entirely unprecedented for an operating system to evolve new API's, technologies, infrastructures, etc, as hardware evolves. Windows has done it. Macosx has done it. Unless you have a crystal ball, you aren't really going to know enough about 5 or 10 years from now (let alone 30 years) what hardware will look like and what crazy peripherals will exist in order to design something that lasts for ever. Some people call it progress. Others complain on forums ;-)

          Originally posted by getaceres View Post
          It comes Intel with EXA, UXA, GEM, SNA and God knows what else
          GEM is an infrastructure for sharing buffers. Intel/radeon/nouveau drivers all use it.

          EXA/UXA/SNA on the other hand are acceleration APIs within the xserver. And in fact UXA and SNA are just private inside intel's ddx driver.

          I expect windows or macosx have their fair share of three-letter-acronyms. If you all put them in one big pile, it will look like a mess too. :-)

          Originally posted by getaceres View Post
          Nvidia replacing half of the mess with their own private, closed and cryptic implementation
          AMD doing the same on their part

          Everyone has their own implementation of video acceleration and every one supports other features or not depending on their will and I'm ruling out legacy sytems and graphic stacks out of the main three. So now Adobe, Google or whatever other company tries to get hardware acceleration for their product of implement some other fancy feature easily implemented on the unified stack of Windows or OSX and they find bug after bug and it's normal.

          And the situation is not improving. Wayland is taking ages to come out and still we have to see the support it might get from Nvidia and AMD, because without it, it's useless and in the mix comes Mir. Really?
          I suppose the difference compared to proprietary operating systems is that you see the entire development phase from conception to adoption vs abandonment. Well, this is just speculation, since I don't know internals of microsoft/apple, but I would assume they don't announce some new project until it is reasonably far in the development process.

          Anyways, the "problem" with wayland is really just that x11 has been approximately good enough to live with.. and so more focus was placed on getting things right, consideration of lots of different use cases (there *is* more than just desktop these days), etc, rather than getting it out the door yesterday. In the long run, it's a good thing. You have to live with API's for a much longer time than you spend designing them.

          Originally posted by getaceres View Post
          So either Steam or Canonical or anyone else comes into play and gets enough traction to get companies on their side and cleans this mess in a dictatorship way or we continue as we go right now. Contrary to propietary systems we have freedom to implement what we want, but the price to pay is not having features implemented by third parties in a timely manner or implemented at all.
          I don't think it is quite as bad as it sounds. For the open src drivers, there are only two: intel with vaapi and radeon+nouveau with gallium (with user visible API, ie. xvmc/vdpau/omx being provided as gallium state trackers). You are not allowed to count nvidia/amd/other's closed source implementations if making comparisions between proprietary vs free.

          Comment


          • #20
            I think the main issue is not video acceleration by itself, since that can be handed off to gstreamer like Firefox does on linux systems. The problem is more that Chrome is also using gpu acceleration for their UI and they can't guarantee it will work bug-free (imho) primarily due to FGLRX. I can't wait for the radeon driver to kill it so we can finally get decent third party support on Linux. If Nouveau could catch up and Intel would drop vaapi we would be in paradise ><

            Comment


            • #21
              Google philosophy

              Google has a philosophy of making everything idiot-proof. See https://code.google.com/p/chromium/i...tail?id=331072 They won't add local printing to Chrome OS, even as an advanced feature for highly qualified administrators. This looks a lot like more of the same.

              I'd like to see Google reward manufacturers who ship validated implementations of open standards, even if it means users of some hardware are left disappointed.

              Comment


              • #22
                [QUOTE=cynical;402696]I think the main issue is not video acceleration by itself, since that can be handed off to gstreamer like Firefox does on linux systems. The problem is more that Chrome is also using gpu acceleration for their UI and they can't guarantee it will work bug-free (imho) primarily due to FGLRX. I can't wait for the radeon driver to kill it so we can finally get decent third party support on Linux. If Nouveau could catch up and Intel would drop vaapi we would be in paradise >

                Comment


                • #23
                  Originally posted by robclark View Post
                  Well, it's not entirely unprecedented for an operating system to evolve new API's, technologies, infrastructures, etc, as hardware evolves. Windows has done it. Macosx has done it. Unless you have a crystal ball, you aren't really going to know enough about 5 or 10 years from now (let alone 30 years) what hardware will look like and what crazy peripherals will exist in order to design something that lasts for ever. Some people call it progress. Others complain on forums ;-)



                  GEM is an infrastructure for sharing buffers. Intel/radeon/nouveau drivers all use it.

                  EXA/UXA/SNA on the other hand are acceleration APIs within the xserver. And in fact UXA and SNA are just private inside intel's ddx driver.

                  I expect windows or macosx have their fair share of three-letter-acronyms. If you all put them in one big pile, it will look like a mess too. :-)



                  I suppose the difference compared to proprietary operating systems is that you see the entire development phase from conception to adoption vs abandonment. Well, this is just speculation, since I don't know internals of microsoft/apple, but I would assume they don't announce some new project until it is reasonably far in the development process.

                  Anyways, the "problem" with wayland is really just that x11 has been approximately good enough to live with.. and so more focus was placed on getting things right, consideration of lots of different use cases (there *is* more than just desktop these days), etc, rather than getting it out the door yesterday. In the long run, it's a good thing. You have to live with API's for a much longer time than you spend designing them.



                  I don't think it is quite as bad as it sounds. For the open src drivers, there are only two: intel with vaapi and radeon+nouveau with gallium (with user visible API, ie. xvmc/vdpau/omx being provided as gallium state trackers). You are not allowed to count nvidia/amd/other's closed source implementations if making comparisions between proprietary vs free.
                  It's good to have an evolution and in an ideal world all drivers would be open source so you can count on most of them to have adopted the latest patch made for Xorg or even the latest technology that replaces it. Unfortunately that's not the case and when you're a company making software that should run on Linux, you have to take into account the free drivers and the propietary ones and all the standards they support or not and all the bugs they have when supporting those standards. It's not an easy task. On the propietary side (Windows and OSX) there is a unified system, everything uses the latest technology or at least the old one in the transition time (which usually is much shorter than in Linux) so basically you don't have to fight with 20 implementations of the same, each one of them made by every vendor of graphic cards.

                  Comment


                  • #24
                    That's just a very bad excuse.

                    Has anybody looked at the Android code where they handle video acceleration? They've pretty much worn out the if-else statements for the ten gazillion SoCs they have to support on that platform.

                    Comment


                    • #25
                      Originally posted by johnc View Post
                      That's just a very bad excuse.

                      Has anybody looked at the Android code where they handle video acceleration? They've pretty much worn out the if-else statements for the ten gazillion SoCs they have to support on that platform.
                      so, android standardizes on openmax for video accel (encode and decode). Going back a few years, it *used* to be that vendors would just hack up the stagefright layer to make it work with the quirks of their hardware / openmax implementation. I guess the rough equivalent in this scenario would be if nvidia/amd/etc had their own customized version of chromium.

                      I've been further away from android development for the last years, so I could be wrong, but my understanding is that google was trying to get away from this and limit the ability of vendors to hack up the middleware.. although I'm sure there is plenty of 'if (vendor == FOO) ..' type stuff in stagefright. (Again, equivalent to having to put some 'if (vendor == NVIDIA) ..' workarounds in chromium.)

                      But yeah, it seems like a pretty poor excuse to me too. Android has more vendors with their own quirks to workaround, compared to different GPU vendors in the desktop space.

                      Comment


                      • #26
                        Originally posted by robclark View Post
                        so, android standardizes on openmax for video accel (encode and decode). Going back a few years, it *used* to be that vendors would just hack up the stagefright layer to make it work with the quirks of their hardware / openmax implementation. I guess the rough equivalent in this scenario would be if nvidia/amd/etc had their own customized version of chromium.

                        I've been further away from android development for the last years, so I could be wrong, but my understanding is that google was trying to get away from this and limit the ability of vendors to hack up the middleware.. although I'm sure there is plenty of 'if (vendor == FOO) ..' type stuff in stagefright. (Again, equivalent to having to put some 'if (vendor == NVIDIA) ..' workarounds in chromium.)

                        But yeah, it seems like a pretty poor excuse to me too. Android has more vendors with their own quirks to workaround, compared to different GPU vendors in the desktop space.
                        I think this is a great article: https://dolphin-emu.org/blog/2013/09...all-fameshame/ Kinda explains a lot. What I find most interesting is that adreno is (a) the most popular GPU, and (b) has some of the shittiest drivers. They should fix that.

                        On Kubuntu 13.10 it looks like all acceleration is enabled on my Chrome Version 34.0.1847.116 running nVidia 650Ti Boost (great card for the money). VDPAU seems to be handling youtube decoding, as the CPU shows hardly any usage difference when viewing a full-screen HD video. I did go to chrome://flags and turn on all acceleration options (from "default" which tells me nothing, grrr). I don't see a difference in performance though - everything is still plain fast. Perhaps certain nVidia cards have been white-listed after all?


                        Cheers!

                        Comment


                        • #27
                          Right click on the video, "stats for nerds" and there it says if hardware decoding is working or not.
                          It should read something like:
                          Code:
                          accelerated video rendering, hardware video decoding
                          VP8/9 videos (html5) are NOT decoded by hardware btw (no hardware decoding exists), only the h264 streams that come only via the flash player.

                          At least on the Adobe version of flash VDPAU works even with the opensource radeon drivers IF its enabled in /etc/adobe/mms.cfg
                          , but it breaks the plugin on many other pages (crashes). Back when i had a 8200 nvidia it was exactly the same behavior btw.

                          BTW it seems that the Adobe plugin handles hardware accelerated playback just fine, only Google's version chokes (as in "uses 200-300% CPU and its laggy").
                          But 3d acceleration with webgl is crap too. It uses insane amounts of CPU to lag like hell.

                          So, in that link they say mesa is ok for them. Why their own plugin+webgl works like crap with it then (latest git kernel/mesa/xf86-ati version on Radeon HD 8570D)?
                          Once more: the same webgl demos work just perfect in Firefox/Seamonkey with very low CPU usage with the same hardware/d.

                          Comment

                          Working...
                          X