Bug 107516

Summary: Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so
Product: DRI Reporter: Mike <bugs.freedesktop.org>
Component: libdrmAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: kai
Version: DRI git   
Hardware: Other   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=107384
https://bugs.freedesktop.org/show_bug.cgi?id=98629
Whiteboard:
i915 platform: i915 features:

Description Mike 2018-08-07 13:37:38 UTC
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.
Comment 1 Mike 2018-08-07 13:41:31 UTC
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
Comment 2 Mike 2018-08-07 13:44:27 UTC
One more thing. This bug might be firefox-specific, because other OpenGL apps, say, glxgears, use correct driver and get HW accel.
Comment 3 Emil Velikov 2018-08-07 13:49:07 UTC
The FF sandboxing is fairly, ahem, strange. The following Mozilla bug addresses that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1
Comment 4 Mike 2018-08-07 13:58:38 UTC
(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.
Comment 5 Mike 2018-08-07 14:24:52 UTC
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.
Comment 6 Michel Dänzer 2018-08-22 17:03:03 UTC
*** Bug 107660 has been marked as a duplicate of this bug. ***
Comment 7 Michel Dänzer 2018-08-22 17:06:51 UTC
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?
Comment 8 Gian-Carlo Pascutto 2018-09-03 09:35:03 UTC
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.