Closed
Bug 567320
Opened 14 years ago
Closed 14 years ago
WebGL doesn't work using OSmesa
Categories
(Core :: Graphics: CanvasWebGL, defect)
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.
Reporter | ||
Updated•14 years ago
|
Version: unspecified → Trunk
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.
Reporter | ||
Comment 3•14 years ago
|
||
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
Comment 4•14 years ago
|
||
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.
Reporter | ||
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
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
Reporter | ||
Comment 7•14 years ago
|
||
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.
Description
•