2

Well, I wanted to try to check out WebGL on Firefox (v38.0.5 on Linux); and I realized that in about:config, webgl.osmesalib was set to /usr/lib/libOSMesa.so.6, while about:support claimed:

Graphics
--------

Adapter Description: Tungsten Graphics, Inc -- Mesa DRI Intel(R) IGD GEM 20100330 DEVELOPMENT x86/MMX/SSE2
Device ID: Mesa DRI Intel(R) IGD GEM 20100330 DEVELOPMENT x86/MMX/SSE2
Driver Version: 1.4 Mesa 7.10.2
GPU Accelerated Windows: 0/1 Basic Blocked for your graphics card because of unresolved driver issues.
Vendor ID: Tungsten Graphics, Inc
WebGL Renderer: Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

So, I found Blocklisting/Blocked Graphics Drivers - MozillaWiki, which notes:

Mesa drivers are whitelisted if the Mesa version is at least 7.10.3 (see bug 659560).

Exception: with the Nouveau 3D driver, the Mesa version is required to be at least 8.0 (see bug 729817)

Right, so libOSMesa.so.6 doesn't actually check out with 1.4 Mesa 7.10.2, but I thought I'd rebuild from source anyways.

So I got the source of 7.10.3 (MesaLib-7.10.3.tar.gz, MesaGLUT-7.10.3.tar.gz) and libdrm-2.4.24, unpacked, ran PKG_CONFIG_PATH=/path/to/Mesa-7.10.3/libdrm-2.4.24 ./configure --enable-gl-osmesa and make, and indeed, I do get shared library files built libOSMesa.so -> libOSMesa.so.7 -> libOSMesa.so.7.10.3; and if we doubt the version info in the filename, we could also try this:

$ strings -a lib/libOSMesa.so.7 | grep 'Mesa 7'
%u.%u Mesa 7.10.3
OpenGL ES-CM 1.%d Mesa 7.10.3
OpenGL ES 2.0 Mesa 7.10.3

Nice, so now I thought, I'll just replace this library as webgl.osmesalib:

test.png

... and run Firefox with:

LD_LIBRARY_PATH=/path/Mesa-7.10.3/lib LD_PRELOAD=/path/Mesa-7.10.3/lib/libOSMesa.so.7 strace /path/to/firefox -P default -safe-mode -new-instance 2>&1 | grep --color=always 'Mesa.*\.so'

... and strace even tells me the library has been opened:

open("/path/Mesa-7.10.3/lib/libOSMesa.so.7", O_RDONLY) = 4

... and still - I get this in about:support, the same as above:

test2.png

So, it's still referring to Mesa 7.10.2, regardless - and I have no idea why?

Btw, I just now realized that the config setting webgl.osmesalib may be something hanging in my profile from earlier versions, because if I start firefox with default profile and safe mode, all I get is gfx.blacklist.suggested-driver-version and gfx.prefer-mesa-llvmpipe settings:

test3.png

So - how can I persuade firefox, to try the newly built Mesa libraries, instead of the old ones?

0

Ok, I think I understand now: as per Enable OpenGL 2.0 and WebGL for Intel GMA3150 in Ubuntu, what this new Firefox sees as a Graphics driver, is not some specific file version, but that which is reported by glxinfo:

$ glxinfo | grep -i "OpenGL version"
flushing GPU caches before/after each draw call
OpenGL version string: 1.4 Mesa 7.10.2

Then I configured again with a prefix /usr (otherwise the default is /usr/local), which is where Ubuntu Natty wants these stored; and did install:

./configure --enable-gl-osmesa --prefix=/usr
sudo make install

And then, just for a while, glxinfo returned 7.10.3, which is what Firefox would have seen; but for one I ran out of disk space; and for another, now after reboot I get:

$ glxinfo 
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig

And this apparently (graphics - Error: couldn't find RGB GLX visual or fbconfig ubuntu 12.04) requires messing with xserver-xorg, so it is a bit more complicated than just replacing the library, it seems...


Edit: actually got it: From this Problems with nvidia drivers in 12.2 - glxinfo "couldn't find RGB GLX visual", I learned to do:

$ grep -B2 EE /var/log/Xorg.0.log
...
[    37.353] (II) AIGLX: Trying DRI driver /usr/lib32/dri-alternates/i915_dri.so
[    37.353] (II) AIGLX: dlopen of /usr/lib32/dri-alternates/i915_dri.so failed (/usr/lib32/dri-alternates/i915_dri.so: cannot open shared object file: No such file or directory)
[    37.353] (EE) AIGLX: reverting to software rendering
...

I mentioned that I ran out of disk space; so I did this (after a sudo make install of Mesa):

sudo mv /usr/lib/dri /media/external/_mv/
sudo ln -s /media/external/_mv/dri /usr/lib/
sudo mv /usr/lib/egl /media/external/_mv/
sudo ln -s /media/external/_mv/egl /usr/lib/

Then we actually need to restart x-server, so it can "see" the .so files in the symlink locations upon load, which as per How can I restart x-server from the command line? - Ask Ubuntu, for me was sudo service gdm restart

After that, got this:

$ LIBGL_DEBUG=verbose glxinfo
name of display: :1.0
libGL: OpenDriver: trying /usr/local/lib/dri/i915_dri.so
libGL error: dlopen /usr/local/lib/dri/i915_dri.so failed (/usr/local/lib/dri/i915_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: i915_dri.so
libGL error: driver pointer missing
....

... and simply did:

sudo ln -s /media/external/_mv/dri /usr/local/lib/

... and voila:

$ LIBGL_DEBUG=verbose glxinfo
name of display: :1.0
libGL: OpenDriver: trying /usr/local/lib/dri/i915_dri.so
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
flushing GPU caches before/after each draw call
display: :1  screen: 0
direct rendering: Yes
...

... except, not even this is good enough for this Firefox:

test.png

Ah, well...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.