Announcement

Collapse
No announcement yet.

The GPU Acceleration Situation In Firefox 6

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

  • The GPU Acceleration Situation In Firefox 6

    Phoronix: The GPU Acceleration Situation In Firefox 6

    Mozilla Firefox 6.0 is to be officially released on Tuesday (it's already out if you look on FTP mirrors) with faster performance, better start-up times, improved plug-in management, greater HTML5 support, more permission controls, and several other features. What's not talked about much, but is huge for the affected Linux users, is that the GPU acceleration situation begins to be sorted out...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I don't understand. Wasn't Gallium3D supposed to be better than classic by now? And even have less bugs?

    What's going on?

    Comment


    • #3
      Originally posted by RealNC View Post
      I don't understand. Wasn't Gallium3D supposed to be better than classic by now? And even have less bugs?

      What's going on?
      The bug Firefox had with the Gallium drivers was within Firefox itself. They tracked down and fixed that bug, but didn't want to change the whitelist in FF6 without a full round of testing first.

      FF7 will still only require Mesa 7.10.3, so the drivers have been good at least since that point. If I recall, the Gallium drivers were fine in 7.10.0 as well, it was some bug affecting both classic and Gallium that made them bump it to 7.10.3.

      Edit: the actual bugfix may have been ported from FF7 into 6, so if you run FF6 and bypass the whitelist it may work correctly. But i'm not 100% sure whether that bug got fixed there or not.
      Last edited by smitty3268; 14 August 2011, 07:34 AM.

      Comment


      • #4
        Originally posted by RealNC View Post
        I don't understand. Wasn't Gallium3D supposed to be better than classic by now? And even have less bugs?

        What's going on?
        Here is the summary for you.

        Comment


        • #5
          FF6 also brings updates to the Mozilla linux build

          They've updated the build to use gcc 4.5, with -03 optimization flags and PGO. So Mozilla builds should be noticeably faster than before, although I'm not sure if that will carry over into distro builds or not.

          Comment


          • #6
            Originally posted by smitty3268 View Post
            They've updated the build to use gcc 4.5, with -03 optimization flags and PGO. So Mozilla builds should be noticeably faster than before, although I'm not sure if that will carry over into distro builds or not.
            Arch Linux started using PGO with firefox 5.0[1] and I think firefox overrides the CFLAGS optimization level. I'm sure you could file bug reports and get it enabled in other distros.

            [1] https://projects.archlinux.org/svnto...86_64/PKGBUILD

            Comment


            • #7
              "en masse"

              Comment


              • #8
                GPU acceleration in a web browser is great and all.. But what about the Javascript performance? Firefox still lags behind Chromium in Javascript performance and it doesn't seem to me like they're doing a whole lot about it..

                Comment


                • #9
                  Originally posted by Sidicas View Post
                  GPU acceleration in a web browser is great and all.. But what about the Javascript performance? Firefox still lags behind Chromium in Javascript performance and it doesn't seem to me like they're doing a whole lot about it..
                  That's incorrect. In a few days after FF6 is released, the Type Inference work will land on mozilla-central, which brings some pretty massive js performance improvements on some tests. Then they are working on improving their garbage collector to be incremental and generational, which will make another big improvement. Then will come IonMonkey, which will allow further optimizations.

                  There's a lot of work going on to improve performance.

                  Comment


                  • #10
                    They still need a lot of work on the JS engine in Firefox, for sure. I've been working on some WebGL+JS game code this summer, and Chrome is currently the only browser than can handle it. Firefox supports all the necessary features, but the physics engine just runs so pathetically slow that it's not even funny; brings the whole game down to slideshow framerates.

                    I haven't gotten a lot of confirmation out of the Google guys on what exactly V8 is doing (and digging through the code is something I don't have time for), but I believe one of the things they've done is work towards a number of optimizations on JavaScript math libraries, e.g. glMatrix or the vector library in Closure. These libraries basically just create JavaScript Array objects or Float32Array objects with 2-4 components and then implement procedural-style functions for manipulating them. Possibly type-inference will help a lot, but V8 might be going so far as to detect these "special" arrays and optimizing them specially.

                    Of course, JavaScript is still an utter pain in the arse to use for anything game-related. When your fundamental math types are heap-allocated, garbage-collected, pass-by-reference objects, you run into some serious performance and usability issues. Imaging if scalars acted like that as well: programming anything would be a pain in the arse. I've had some talks with the Chrome engineers about extending JavaScript with native SIMD vector types with all the characteristics one would expect out of a well-implemented C++ 3D library. I don't know what will come out of that, but Web Games fans should hope that they incorporate that feature. It alone will give a huge boost to both performance and to the general usability of JavaScript as a games language.

                    (On a side note, one of the primary reasons I know of that many game engines write their own scripting languages instead of using Lua or JavaScript is because of that very issue: making your vector types be regular fat objects is horrific in just so many ways. The other big reason to avoid general purpose high level languages is that their garbage collectors wreck havoc on game performance, and a scripting language designed for game developers rather than for protecting idiots from themselves can be a little less "safe" in terms of memory management while still allowing rapid prototyping and development and offer significantly better performance than what any JavaScript runtime could ever hope to achieve... although admittedly most one-off languages don't have nearly as sophisticated runtimes and JITers as the JavaScript runtimes, because frankly optimizing out an inner loop in a micro-benchmark like the JS engines do so well is utterly useless in real life.)

                    Comment

                    Working...
                    X