Announcement

Collapse
No announcement yet.

Firefox Developers Have Issues With Linux GPU Drivers Too

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

  • #31
    Originally posted by bridgman View Post
    When the GLES-over-DX shim was announced last year one of the big concerns at the time was that it would result in poor Linux support, since most of the testing and bug fixing work would improve the shim and the DX driver implementations, and that the browser GL ES code would end up being tweaked for the GLES-over-DX implementation rather than for real-world GL drivers.

    IIRC the consensus was "hey it could have been worse, WebGL could have been implemented natively over DX" and the pushback died down, but IIRC the decision to use the GLES-over-DX shim was because there were problems running with GL drivers on Windows, and at first glance it seems as if we are just running into those same problems now on Linux (having avoided them on Windows by using DX instead).
    As it has turned out this hasnt become an issue as using OpenGL with the DX interop(which basically gives OpenGL the ability to read and write to DX buffers directly in the video/system memory, thus avoiding a lot of translations and copy back and forth headache) much faster than ANGLE for complex webgl pages.

    Nvidia introduced the new extension and AMD bought OpenGL ES to their desktop drivers, which shows that the big two are not turning their back on OpenGL.

    Comment


    • #32
      Sounds good. Thanks for the info - I'm still learning all this.

      In a nutshell, then, it seems as if the core issue here is that there are a bunch of relatively new GL ES driver implementations around and those code paths are being taken if available.

      This has some similarities to the situation with new KWin versions -- in most cases the user experience with applications is improved if work-in-process extensions and features are exposed even in a "mostly working" state, but some applications (particularly those which are smart enough to dynamically select from multiple back-ends at runtime) end up running on an API which is exposed but still in development rather than a "less preferable" API whose implementation may be a lot more mature.

      I don't think we have found a good answer for this other than more communication between app and driver developers. This particular issue will probably go away on its own as the GL ES implementations mature, but the core issue (conflict between the need to expose WIP functionality to support driver development and the need for exposed APIs and extensions to be rock solid ie not in development) remains unresolved. We really need some kind of extension/API mechanism with a bit more subtlety, ie a third "this is exposed but in development, so if you *can* work with a lower API level you should" state between "not exposed" and "exposed".

      If there are runtime options to (for example) ignore GL ES even if it is exposed that would probably be a big help in the short term.

      Thanks again for the info.

      Comment


      • #33
        I wonder how much longer are companies going to keep creating stopgap solutions (like FF4's or Unity 2D, or whatnot) until they finally get together and start helping the few guys who're actually working on graphics drivers (the few devs from Red Hat, Intel and AMD) to finally get the graphics drivers into good shape which imo is a WAY better alternative than what they keep doing for years, which is creating their own fallbacks, blacklists, workarounds resulting into additional headaches, wasted time and worse products then those on window$/mac.

        Comment


        • #34
          Originally posted by cl333r View Post
          I wonder how much longer are companies going to keep creating stopgap solutions (like FF4's or Unity 2D, or whatnot) until they finally get together and start helping the few guys who're actually working on graphics drivers (the few devs from Red Hat, Intel and AMD) to finally get the graphics drivers into good shape which imo is a WAY better alternative than what they keep doing for years, which is creating their own fallbacks, blacklists, workarounds resulting into additional headaches, wasted time and worse products then those on window$/mac.
          probably never

          Mozilla doesn't care much about Linux (read marketshare) Canonical and the Spaceman is too busy trying to turn Ubuntu in a Mac clone and Intel doesn't want to move to the newer architecture (gallium3d)

          + there is no other way (financial sustainable) of funding the FOOS driver devs outside of hiring them in a company

          Comment


          • #35
            Originally posted by cl333r View Post
            I wonder how much longer are companies going to keep creating stopgap solutions
            As said above, probably never. Linux is full of such stopgaps where it seems "Wrapper it!!!" has become the norm instead of working on one unified, refined solution.

            Comment


            • #36
              Originally posted by 89c51 View Post
              probably never

              Mozilla doesn't care much about Linux (read marketshare) Canonical and the Spaceman is too busy trying to turn Ubuntu in a Mac clone and Intel doesn't want to move to the newer architecture (gallium3d)

              + there is no other way (financial sustainable) of funding the FOOS driver devs outside of hiring them in a company
              Someone could say that Mozilla cares about Linux because it's part of their mission.

              If you don't know what a mission is: http://en.wikipedia.org/wiki/Mission_statement

              Comment


              • #37
                Originally posted by blackshard View Post
                Someone could say that Mozilla cares about Linux because it's part of their mission.

                If you don't know what a mission is: http://en.wikipedia.org/wiki/Mission_statement
                to put it better

                It doesn't care enough to hire a dev or two to help on the graphic stack. Its not their mission. They care about the internet. Also linux doesn't have the marketshare to have more mozilla people working on it. If it was 50% of the desktop market then you would even have QT-mozilla or even E17-mozilla. And this is not a Mozilla problem.

                Comment


                • #38
                  bastards...

                  Comment


                  • #39
                    NVidia is NOT disabled on linux

                    From one of the developers:

                    NVIDIA proprietary driver is not buggy, for what we are doing (which is pure OpenGL). We are enabling hardware acceleration on X with the NVIDIA proprietary driver.

                    The FGLRX driver is crashier, it's blacklisted at the moment, this could change (everything hopefully will change :-) )

                    Yes, you can turn the whole driver blacklisting off by defining the MOZ_GLX_IGNORE_BLACKLIST environment variable. Just launch firefox with this command (you can use it in the properties of your desktop icon, too):

                    MOZ_GLX_IGNORE_BLACKLIST=1 firefox

                    We did this blacklisting to put and end to the endless series of linux crashes that were caused by buggy graphics drivers, and were causing lots of grief among linux users ("firefox 4 is crashy!"). This was the top reason for crashiness on linux.

                    We are looking forward to un-blacklisting drivers as soon as they get good enough

                    Comment


                    • #40
                      Originally posted by 89c51 View Post
                      then you would even have QT-mozilla
                      It's coming.

                      http://blog.johnford.info/linux-qt-b...g-generated-2/

                      Comment


                      • #41
                        FYI, if you want to help test

                        It's quite possible the newest drivers have fixed issues and it's just older ones that are crashing. You can test, and report info by doing this:

                        For now, the best way that you
                        can reproduce the crashes and failures that we've been experiencing is to grab
                        a Firefox 4 nightly (not beta, since they have had some bugs fixed), run with the environment variable
                        MOZ_GLX_IGNORE_BLACKLIST defined, go to about:config and set
                        webgl.enabled_for_all_sites, and go to:
                        https://cvs.khronos.org/svn/repos/re...nce-tests.html
                        Run the tests. If a driver can run them all with only few test failures and no
                        crash, it's quite probably good enough.

                        Comment


                        • #42
                          It will probably take Canonical to save Linux.

                          Comment


                          • #43
                            Originally posted by schmidtbag View Post
                            if the ff devs are focusing explicitly on open source drivers and not proprietary, then really, they're idiots.
                            Huh? We whitelist the proprietary NVIDIA driver precisely because it's good...

                            Comment


                            • #44
                              Originally posted by Melcar View Post
                              Man, that quote made me rage a bit. I donīt see why they could not just focus on the proprietary drivers and call it a day.
                              The NVIDIA proprietary driver is whitelisted.

                              Comment


                              • #45
                                The question is if a WHITE or BLACKLIST is used... that's the opposite.

                                Comment

                                Working...
                                X