Firefox Developers Have Issues With Linux GPU Drivers Too

[RealNC]

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

Troll attempt failed. Try again later.

[transwarp]

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.

So would the real solution to have a non-standard way of signaling that the API is a WIP, rather than having it marked as working? Something like the -moz-rounded-corner CSS settings for Mozilla, or the matching ones for Webkit back when they were testing it out. That way, the only applications that see that a WIP feature are there are the ones that are specifically testing out that feature in that driver. Are there any cases where other applications would want to see WIP features as enabled? Once it does work, the driver reports it in the standard way, like -rounded-corners in modern CSS.

Am I totally off base with this?

[rapsure]

I agree with the Mozilla devs that the majority of the drivers are broke. I'm pretty sure that webGL is using shader code. Shader code in the opensource drivers isn't even working for very many programs. I've run the drivers, including the proprietary nvidia, and amd drivers, and the opensource nouveau and r300 mesa classic, and r300 gallium, and r200. For the most part that sums up the majority of the current work. The best driver is the nvidia driver for getting the opengl correct and not crashing. AMD is the second best driver for the opengl correctness and somewhat not crashing. The opensource drivers are a long way from getting opengl 2.0 stable. I tried loading googleearth with mesa 7.9 and gallium and the r300 and the program didn't even load. I got the same result with the nouveau driver. Googleearth did load using the classic mesa stack with the r300 which is good but then again that driver doesn't support opengl 2.0. There are a lot of programs that use opengl 2.0 that just simply don't work at all on the opensource stack.

[glisse]

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/registry/trunk/public/webgl/sdk/tests/webgl-conformance-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.

We do have a good OpenGL test suite, maybe not the definitive answer but it has thousands of GL test see :

http://cgit.freedesktop.org/piglit/

WebGL is not suddenly a savior on GL testing, thought any new test suite is welcome as hopefully it will experiments new rendering path.

That being said from bugs i have seen my feeling is that the GL part is not really at fault. I am pretty sure that all open source driver for big tree AMD, Intel & NVidia does support enought GL feature on recent enought hw to run the vast majority of WebGL content (if you would be able to copy the WebGL code into a standalone program it would run properly).

From what i gather the issues are with GLX and GL context switching/binding, it's one area that is barely tested with open source driver simply because pretty much all GL application that exist create one and only one GL context and bind it once at the very beginning. To me it seems that with WebGL we suddenly face a tons of GL context and firefox happily switch btw them and send command, i believe the root of most of the issues are there. Hard to says who is to blame as context switching and GL command submission should be done carefully.

For raising the issue i believe the mesa mailing list is likely the most appropriate place (i am sure that all X developer of the big three are subscribed to both Xorg & mesa but some of the mesa folks who have broad knowledge on this might not be on Xorg mailing list).

http://lists.freedesktop.org/mailman/listinfo/mesa-dev

I wish those firefox issues were signalled to open source driver dev earlier ...

[Yfrwlf]

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:

Results: (5234 of 5310 passed)
With:
FGLRX 8.78.3-100920a-105558C-ATI
ATI Radeon HD 4850 X2
Minefield 4.0b10pre (2011-01-14)

[Yfrwlf]

It will probably take Canonical to save Linux.

Who has put more interest, Canonical or Red Hat, into cross-distro (real) Linux standards? Linux just needs more standards for interoperability/compatibility and ease-of-use, and getting the standards/frameworks/whatever sorted out and upgraded to modern systems requiring less maintenance and better ease-of-use and adoptability for both developers and end users should be the highest priority. Has that been something Canonical has focused on much though? Have they ensured that all of the new programs they are rolling out are using Freedesktop.org and other standards, or if they are replacing/upgrading those standards/frameworks are they notifying Freedesktop.org or other standards bodies?

I know Red Hat has contributed lots, and I'm no guru on the subject, but it seems like Red Hat has contributed a lot of fundamental systems which have become standards, while I haven't seen the same from Canonical yet. A lot of what Canonical has done seems to be just for helping themselves, and not for helping cross-distro standards, which of course in turn would help themselves.

I just wish there was interest in specific projects and Linux software in general, instead of the interest being geared towards one distro. That interest conflicts with cross-distro standards. Maybe then we'd see an actual cross-distro installation standard so that game and other software companies would be less scared of supporting Linux, not to mention hardware companies and drivers (a company releasing a closed or open source driver is besides the point; users should have an easy way of installing newer or different drivers period and should not be held captive by their distro of choice, not to mention there is no way to get a driver into the kernel and into a distro for hardware that is totally bleeding-edge).

[bridgman]

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.

Your response suggests that it actually *is* the same situation - but I'm not talking about blame and fingerpointing, just how the problems are happening. Kwin apparently added code some time back which used newer extensions and API levels *if* they were available. Some time later, the in-development drivers started exposing new in-development extensions and API levels, KWin automatically started using them (with no ability to influence that decision, just to blacklist drivers) and Bad Things happened.

The situation seems similar here -- automatic selection of back ends, automatic use of in-development APIs, and automatic Bad Things. The question is whether there is or could be a runtime mechanism to influence the choice of back end (eg forcing to not use a brand new or in development API choice).

[bridgman]

EDIT (this is how we edited back in the 70s ) - glisse's post does suggest that the problems might actually happen no matter which back end API was selected (assuming that submission from any of a large number of different contexts happens whether GL or GL ES is used) so I agree this *may* actually be different from the KWin situation.

[deanjo]

EDIT (this is how we edited back in the 70s )

I want to see you do it how it was edited in the 80's. Now that the forum background is white that liquid paper should blend right in on your monitor......

[bjacob]

We do have a good OpenGL test suite, maybe not the definitive answer but it has thousands of GL test see :
http://cgit.freedesktop.org/piglit/

Thanks, I didn't know about that.

From what i gather the issues are with GLX and GL context switching/binding, it's one area that is barely tested with open source driver simply because pretty much all GL application that exist create one and only one GL context and bind it once at the very beginning. To me it seems that with WebGL we suddenly face a tons of GL context and firefox happily switch btw them and send command, i believe the root of most of the issues are there. Hard to says who is to blame as context switching and GL command submission should be done carefully.

Hm, I am pretty sure that we have lots of crashes already with only 1 WebGL context at hand and no GL-accelerated compositing, which would really mean only 1 OpenGL context, but I couldn't swear that as that depends on fine details of what the user did when they got the crash they reported.

Also, we have implemented an 'OpenGL debug mode' that checks that the GL context a GL call is intended to apply to is indeed current at the time of the call, and are making users reproduce crash with it to catch such errors first before we start blaming drivers ;-) Basically it works like this: GLContext::drawArrays checks that the 'this' pointer is the pointer to the current GLContext for this thread. Then user code calls myGLContext.drawArrays() instead of directly calling glDrawArrays().

For raising the issue i believe the mesa mailing list is likely the most appropriate place (i am sure that all X developer of the big three are subscribed to both Xorg & mesa but some of the mesa folks who have broad knowledge on this might not be on Xorg mailing list).

http://lists.freedesktop.org/mailman/listinfo/mesa-dev

OK, will write to this list.

I wish those firefox issues were signalled to open source driver dev earlier ...

Actually, it's only fairly recently that we've become aware of the magnitude of the problem, when we turned WebGL on by default.