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

[Benoit Jacob]

----- 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
https://bugzilla.mozilla.org/show_bug.cgi?id=616416
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,
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux-debug/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-debug/
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
https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server

Apparently it's possible to download them and use them from GDB, as explained on that page, I've just never used it.
https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_.2f_Mac_OS_X

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):

http://hg.mozilla.org/mozilla-central/file/62157abe57bf/content/canvas/test/webgl/test_webgl_conformance_test_suite.html

Cheers,
Benoit