Firefox Developers Have Issues With Linux GPU Drivers Too

[Harsh]

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.

[bridgman]

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.

[cl333r]

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.

[89c51]

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

[deanjo]

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.

[blackshard]

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

[89c51]

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.

[hax0r]

bastards...

[smitty3268]

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

[deanjo]

then you would even have QT-mozilla

It's coming.

http://blog.johnford.info/linux-qt-builds-of-firefox-now-being-generated-2/