Firefox Developers Have Issues With Linux GPU Drivers Too

[smitty3268]

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.

[e8hffff]

It will probably take Canonical to save Linux.

[bjacob]

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...

[bjacob]

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.

[Kano]

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

[bjacob]

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.

[bjacob]

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

[bjacob]

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.

[bjacob]

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.

[bjacob]

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.