Announcement

Collapse
No announcement yet.

Firefox Developers Have Issues With Linux GPU Drivers Too

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

  • #46
    Originally posted by siride View Post
    I would hope that the Firefox devs would open a dialog with the Xorg folks to fix the specific issues they have.
    This is already happening: on IRC (#gfx on mozilla's irc) at the moment, and soon on the xorg-devel list. Good stuff is going to come out of that.

    Maybe they could even hire an Xorg dev? We need more and now that Firefox is interacting with X on a deeper level,
    We're actually not interacting with X on a deep level at all here. What we're talking about here really is pure OpenGL. X is almost entirely abstracted behind the OpenGL API. All what we need is a good implementation of OpenGL itself. Contrast this with e.g. composited window managers, which do much more complex X stuff.

    Comment


    • #47
      Originally posted by mirv View Post
      Not sure I'd take that quote seriously. Many others don't have such troubles under Linux, and a single comment there without anything in the way of what is actually going wrong doesn't prove much. It could well be firefox's internals that need some fixing up. Now if such a statement had some actual evidence to back it up, that would be a different story.
      Factual evidence:
      https://bugzilla.mozilla.org/show_bug.cgi?id=589546
      https://bugzilla.mozilla.org/show_bug.cgi?id=616416
      https://bugzilla.mozilla.org/show_bug.cgi?id=622294

      Do your own queries in our crash database if you want:
      http://crash-stats.mozilla.com/products/Firefox

      Comment


      • #48
        Originally posted by schmidtbag View Post
        that is an excellent point, but as i see it (based on my previous post), its mostly the principal of WHY they didn't add it. i'm sure most people could care less otherwise.
        Yep. Right now, most users don't care about WebGL or about hardware acceleration. On the other hand, they do care about crashes. That's why we're being conservative here.

        Comment


        • #49
          Originally posted by chrisr View Post
          Are the Firefox developers raising bugs for the graphics drivers in bugzilla?
          Sometimes I've done that, e.g.
          https://bugs.freedesktop.org/show_bug.cgi?id=32238
          I've even sent a patch,
          https://bugs.freedesktop.org/show_bug.cgi?id=31837

          But really what was missing so far was a good OpenGL test suite. Now that WebGL is providing one,
          https://cvs.khronos.org/svn/repos/re...nce-tests.html
          OpenGL implementers will have something very concrete to test their drivers on, and we'll be able to whitelist drivers which succeed at it.

          Comment


          • #50
            Originally posted by bridgman View Post
            Take all of the following with a grain of salt because I'm just coming up to speed on it myself, but...

            The only part of that discussion I have problems with is "Heck, we’re even disabling WebGL for most Linux drivers, last I checked…". The statement implies that WebGL is a relatively easy thing to support, and if *that* has problems then everything *else* must be worse.

            I believe the reality is quite different. WebGL is relatively new, and its implementation seems to differ significantly between browser implementations. Some (Chromium for example) can run WebGL over regular GL, while most of the others require a GL ES implementation because they pass the WebGL validation work down to the graphics driver and WebGL basically corresponds with GL ES (2.0, I think) rather than GL.
            WebGL is not easy to support at all for a driver, because WebGL exposes, say, 90% of the OpenGL API to random scripts from the web. So driver bugs become security flaws.

            The good news is that WebGL has a good conformance test suite,
            https://cvs.khronos.org/svn/repos/re...nce-tests.html
            and thanks to it, 1) driver developers can test their drivers (to circumvent the blacklist, define the MOZ_GLX_IGNORE_BLACKLIST env variable) and 2) the various webgl implementations are converging fast so at the moment, almost all webgl demos work equally well in Firefox and in Chrome.

            GL ES implementations are relatively new on the proprietary drivers, and are still a work in process on most of the open source drivers.
            Even though the WebGL API is closest to OpenGL ES, WebGL implementations don't require OpenGL ES drivers. Instead, WebGL implementations carry their own abstraction layer to be able to talk to either OpenGL or OpenGL ES (or even Direct3D on windows, using ANGLE).

            The discussion following that post seems to suggest that Chromium/Chrome still has an advantage for running WebGL because of its ability to run over a GL stack rather than relying on a "tight and robust" GL ES implementation to perform the WebGL validation work.
            Again, Firefox too is able to run WebGL directly on top of OpenGL.

            Comment


            • #51
              Originally posted by Tares View Post
              Well, I hope I will be able to force hardware acceleration on my nvidia blob if not I will be not pleased xD
              The NVIDIA proprietary driver is whitelisted, so you won't need to do anything: it runs WebGL out of the box.

              You can even enable GL compositing which will greatly increase WebGL performance (but hurt performance in other contexts, sadly, due to missing GL-XRender interop code at the moment, something we hope to fix soon) by going to about:config and setting layers.acceleration.force-enabled.

              Comment


              • #52
                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 :-) )

                We are looking forward to un-blacklisting drivers as soon as they get good enough
                AMD/ATI do you hear that? After all those years of development and with generous code flowing from windows devs, why do you people have a bag full of cockroaches that you service to your linux customers with the label of "driver"? Its time for you to wake up and really fix issues!

                Comment


                • #53
                  Originally posted by Kano View Post
                  The question is if a WHITE or BLACKLIST is used... that's the opposite.
                  C'mon, no need to argue over words, it's so intricate anyway. Among all GL platforms, GLX is blacklisted, but inside of it, the NVIDIA proprietary driver is whitelisted.

                  PS. I used to be a huge fan of Kanotix and am currently running aptosid which I believe is a descendant of Kanotix.

                  Comment


                  • #54
                    @bjacob

                    Kanotix is based on stable now - but of course i have got test images with squeeze, but only for those who ask. I have got nothing to do with the distro you use.

                    Comment


                    • #55
                      Originally posted by Kano View Post
                      @bjacob

                      Kanotix is based on stable now - but of course i have got test images with squeeze, but only for those who ask. I have got nothing to do with the distro you use.
                      Ah OK, sorry I thought that aptosid was an offspring of Kanotix (via sidux). Anyway, Kanotix has been invaluable to me as a live CD with LaTeX running out of the box.

                      Comment


                      • #56
                        Hark!

                        This is one of the MANY reasons I'm staying away from Intel video chipsets in the future, even the integrated graphics of Sandy Bridge is pretty sweet from a performance-per-watt perspective.

                        Comment


                        • #57
                          Originally posted by bridgman View Post
                          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.
                          Damnit, this is not the same situation of "new versions of KWin". You completely get it wrong -- you aren't the first and won't be the last though.

                          The parts that lead to bad experiences in KWin have mostly not been changed since 4.0!
                          What has changed were drivers which reported "no I don't support this" in 2008 while now they do "I do support this" while the later is not the case in reality.
                          You can't ask KWin devs to try out the drivers of the future, no DeLorean there.

                          Comment


                          • #58
                            Originally posted by bjacob View Post
                            We're actually not interacting with X on a deep level at all here. What we're talking about here really is pure OpenGL. X is almost entirely abstracted behind the OpenGL API. All what we need is a good implementation of OpenGL itself. Contrast this with e.g. composited window managers, which do much more complex X stuff.
                            Just out of curiosity, are you associated with Mozilla? Just so I have some kind of context for what you're saying here. No offense, but I tend to be somewhat skeptical if it's just what random users are saying.

                            Comment


                            • #59
                              Originally posted by Wyatt View Post
                              Just out of curiosity, are you associated with Mozilla?
                              http://tinyurl.com/4gu8pjq

                              Comment


                              • #60
                                OpenSource drivers are good enough to play Quake 3, but not to show photos moving in circles?

                                Comment

                                Working...
                                X