https://bugs.freedesktop.org/show_bug.cgi?id=107516
Bug ID: 107516 Summary: Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: bugs.freedesktop.org@pm.port0.org
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.
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #1 from Mike bugs.freedesktop.org@pm.port0.org --- 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
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike bugs.freedesktop.org@pm.port0.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=107384
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike bugs.freedesktop.org@pm.port0.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freedesktop.or | |g/show_bug.cgi?id=98629
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #2 from Mike bugs.freedesktop.org@pm.port0.org --- One more thing. This bug might be firefox-specific, because other OpenGL apps, say, glxgears, use correct driver and get HW accel.
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #3 from Emil Velikov emil.l.velikov@gmail.com --- The FF sandboxing is fairly, ahem, strange. The following Mozilla bug addresses that.
https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #4 from Mike bugs.freedesktop.org@pm.port0.org --- (In reply to Emil Velikov from comment #3)
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.
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike bugs.freedesktop.org@pm.port0.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTOURBUG
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #5 from Mike bugs.freedesktop.org@pm.port0.org --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kai@dev.carbon-project.org
--- Comment #6 from Michel Dänzer michel@daenzer.net --- *** Bug 107660 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #7 from Michel Dänzer michel@daenzer.net --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|DRM/AMDgpu |libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #8 from Gian-Carlo Pascutto gcp@sjeng.org --- 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/+/8655d49f657d3878c937f1387b3...
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org