[Mesa-dev] WebGL test suite, and whitelisting drivers / OpenGL implementations in Firefox

Benoit Jacob bjacob at mozilla.com
Tue Jan 18 13:58:30 PST 2011

----- Original Message -----
> On Sun, 16 Jan 2011 16:29:45 -0500, Benoit Jacob <bjacob at mozilla.com>
> wrote:
> > Hi List,
> >
> > I realize that you may well not have time to care about WebGL [1] or
> > Firefox. In that case, I'm still writing because there's a new test
> > suite, namely the WebGL conformance test suite, that may be of
> > interest
> > to help find and fix bugs in OpenGL implementations.
> >
> > The goal of this email is to discuss steps towards whitelisting Xorg
> > OpenGL drivers for WebGL rendering, and more generally for all
> > OpenGL-based features, in Firefox. Although I'm only directly
> > concerned
> > with Firefox, this really applies equally well to all browsers
> > implementing WebGL.
> >
> > OpenGL-based features are disabled by default in Firefox 4 on X11
> > because of OpenGL bugs we've hit [2], and currently only the NVIDIA
> > proprietary driver is whitelisted [3].
> We're definitely interested in the intel driver being whitelisted (or,
> more accurately, in convincing you to not blacklist on linux at all

Unfortunately, we really can't do that. See for example
That's a mainstream news site that uses a JS library ("modernizr") that creates a WebGL context just "to check for html5 features", the problem is that it crashes certain open source drivers.

> so linux developers can actually see bugs so they can get fixed).

Well, people would seldom report bugs directly to you anyway. I still believe that the present email thread is far more effective to fix stuff than that :-)

> So far,
> though, I've had an awful time trying to debug webgl issues under
> firefox, so I haven't spent much time on it.
> For example, right now when I hit that page with:
> MOZ_GLX_IGNORE_BLACKLIST=1 ./firefox -g -P -no-remote
> on Mesa 7.10 or master, with ff 4.0b9 or the current nightly of
> 4.0b10pre, I get a segfault almost immediately:

Weird; perhaps there's something wrong with our builds.

Could you then run again firefox with the same profile, and then go to about:crashes. You should see 1 link there per crash. It gives you a stack trace with symbols (using our symbol server).

> just before that is a GL user error from firefox calling a GL function
> with no context.

Maybe if you could reproduce with MOZ_GL_DEBUG_VERBOSE=1 in a debug build,
that may give us a clue, from the terminal output.

> That may or may not be related, but without debug
> symbols it's hard to tell:
> #0 NoOpGeneric () at glapi_nop.c:120
> #1 0xb784ef07 in ?? () from
> /home/anholt/firefox4.0b10pre/firefox/libxul.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> I tried running under valgrind, but on (eventually) getting to a page,
> valgrind died complaining that it can't handle a general clone() call.

Weird; CC'ing Julian.

> I've been getting bug reports from VMware doing regression testing of
> our driver for webgl, and I think our QA is working on getting it into
> their automated system, so if we just can work out a debug environment
> we should be able to get things in shape to get whitelisted at least.
> Are there really no nightlies/betas with debug symbols? I'd really
> rather not build firefox on my own if I can avoid it.

The nightlies and betas have debug symbols on the server

Apparently it's possible to download them and use them from GDB, as explained on that page, I've just never used it.

If you are looking for a way to automatically run these tests, you may be interested to know that we've already integrated the WebGL test suite as a 'mochikit' (one of our testing frameworks) test. The part that's specific to mochikit is negligible (just the ok() calls and SimpleTest):



More information about the mesa-dev mailing list