Closed Bug 567320 Opened 14 years ago Closed 14 years ago

WebGL doesn't work using OSmesa

Categories

(Core :: Graphics: CanvasWebGL, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: gerard-majax, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a5pre) Gecko/20100520 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a5pre) Gecko/20100520 Minefield/3.7a5pre

Trying to use OSmesa to get software rendering for WebGL on an Intel GMA945 laptop, I'm unable to get it working.

Reproducible: Always

Steps to Reproduce:
1. Get MESA 7.8.1
2. Compile it: CFLAGS=-DUSE_MGL_NAMESPACE ./configure --disable-glu --disable-glut --disable-egl --disable-glw --with-driver=osmesa
3. Enable WebGL for all websites in about:config
4. Set the osmesapath to the freshly compiled lib
Actual Results:  
alex@portable-alex:~/bin$ ~/bin/firefox/firefox -no-remote -P dev
Canvas 3D: creating PBuffer...
Canvas 3D: can't get a native PBuffer, trying OSMesa...
Canvas 3D: can't create a OSMesa pseudo-PBuffer.

Expected Results:  
WebGL canvas should works.

The Mesa library seems to be correctly loaded:
alex@portable-alex:~/tmp/mesa/Mesa-7.8.1$ lsof -p 32168 -n|grep "so"|grep -i mesa
firefox-b 32168 alex  DEL    REG        8,6           1582050 /home/alex/tmp/mesa/Mesa-7.8.1/src/mesa/drivers/osmesa/libOSMesa.so.7.8.1

And it seems to be valid, because the ensureInitialized() call in [http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/GLContextProviderOSMesa.cpp#243] doesn't shows any of the error we should see in case of incorrect entry points [http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/GLContextProviderOSMesa.cpp#92]

$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Version: unspecified → Trunk
I followed the same steps with an ATI FIREGL v3100
Our OSMesa implementation changed recently -- USE_MGL_NAMESPACE is no longer needed.  You should even be able to grab the osmesa provided by your distro and use it directly.
I just tried both :
 - Removing my osmesa lib path from about:config, thus relying on Ubuntu 10.04's one ;
 - Recompiling OSMesa, but without USE_MGL_NAMESPACE.

Both ended the same way : doesn't work. Exactly the same behavior as reported before.

BuildID: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a5pre) Gecko/20100520 Minefield/3.7a5pre
Hm, I would still suspect a build problem on your side. Can you do this:

  nm libOSMesa.so | grep gl

and

  nm libOSMesa.so | grep mgl

so we can see what prefix is actually used. Here of course, replace libOSMesa.so by the actual path to your libOSMesa.so library.

Also, can you please retry against current minefield (or the latest nightly build) and tell us again the console error messages you're getting.
Okay, just retried with "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.3a6pre) Gecko/20100616 Minefield/3.7a6pre".

The grep mgl doesn't return anything. The grep gl on the other hand is quite successful :
alex@portable-alex:~/tmp/mesa/Mesa-7.8.1/lib$ nm libOSMesa.so.7.8.1 | grep gl|wc -l
1144

But now it works with the same library than the other day. Something has changed, and in good way !

On some code of us (not publicly available), I get the following:
UseProgram: program was not linked successfully
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
This uniform location corresponds to another program
Great that it's now working!

The new errors that you're getting are because we now check much more carefully what your javascript code is doing, and we enforce much more strictly the webgl spec. Adapt your JS code, or file a bug if you think that some of our checking is wrong ;-)
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Well to be honest, it's not me who wrote this code :)
If you have some tips that might help me debug, that would be grateful.
You need to log in before you can comment on or make changes to this bug.