With recent build of libdrm (2.4.93) Mozilla Firefox cannot use accelerated WebGL, use software emulation instead. HW. AMD RX560 and AMD WX2100 (RX550). SW. Ubuntu 16.04 with kernels 4.17.X and 4.18.rc from http://kernel.ubuntu.com/~kernel-ppa/mainline/, plus Oibaf's PPA builds of drm, mesa, etc. https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers Symptoms. Firefox works OK, but on site with WebGL it works very slow - due to fallback to software GL rendering. Note. about:support page in Firefox DOES show correct driver info: WebGL 1 Driver Renderer X.Org -- AMD Radeon Pro WX2100 (POLARIS12, DRM 3.26.0, 4.18.0-041800rc6-generic, LLVM 6.0.1) But, on WebGL site (ex. windy.com), swrast_dri.so get loaded and eats all CPU cores.
Possibly related to bugs 107384 and/or 98629. If firefox start with LIBGL_DEBUG=verbose parameter, it shows: libGL error: MESA-LOADER: failed to retrieve device information libGL error: unable to load driver: amdgpu_dri.so libGL error: driver pointer missing libGL error: failed to load driver: amdgpu I.e. it cannot retrieve device info (and name of driver as "radeonsi"), trying to load non-existant amdgpu_dri.so, then fallbacks to swrast_dri.so
One more thing. This bug might be firefox-specific, because other OpenGL apps, say, glxgears, use correct driver and get HW accel.
The FF sandboxing is fairly, ahem, strange. The following Mozilla bug addresses that. https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1
(In reply to Emil Velikov from comment #3) > https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1 Indeed, this is Firefox's problem. Аlthough security.sandbox.content.read_path_whitelist trick didn't work for me, I think this bug should be resolved as INVALID.
PS. security.sandbox.content.read_path_whitelist works. Need to add /sys/ (with trailing slash, as https://wiki.mozilla.org/Security/Sandbox says), and restart Firefox.
*** Bug 107660 has been marked as a duplicate of this bug. ***
Emil, as it might take a while for users to get the related Firefox sandbox change, would it be possible for libdrm to fall back to the same method that worked before?
To clarify the underlying cause of this: >Earlier commit reworked our sysfs handling to use realpath. >Sadly that backfired since the Firefox sandboxing mechanism rejects >that. Despite the files/folders being in the allowed list, of the >sandboxing mechanism. The problem is that the underlying implementation of realpath() in libc will issue lstat calls on each of the path components. In Mesa's case, this will cause it to try to stat /sys, which is not on the list of allowed paths. This in turn causes the realpath() call to fail. If this failure isn't handled things broke. Firefox 62 and later will now specifically allow the stat call (only). >Oddly enough, the Chromium sandboxing doesn't complain about any of >this. I'm not sure how much of Chromium's GPU sandbox is enabled by default (on non-Chromebooks), but they literally just did the same fix as we did a few days ago: https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a%5E%21/content/gpu/gpu_sandbox_hook_linux.cc
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.