Closed Bug 1010527 (slow-linux-webgl) Opened 10 years ago Closed 3 years ago

WebGL composites slowly on Linux by default

Categories

(Core :: Graphics: CanvasWebGL, defect, P3)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
All
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jgilbert, Unassigned)

References

(Depends on 2 open bugs)

Details

(Whiteboard: [gfx-noted]) 

On Linux, we don't have a fast compositing path right now for WebGL. This means we do a readback of each frame before sending it to the compositor. This is really slow, and the reason for most reports on Linux regarding framerate differences between Chromium and Firefox.
Note that many users with recent OpenGL drivers should be able to force enable OpenGL Layers with "layers.acceleration.force-enabled".
See Also: → 942302
Depends on: ogl-linux-beta, 942302
I'm getting very bad WebGL performance when Firefox was started while the KDE KWin compositor was active. At http://carvisualizer.plus360degrees.com/threejs/ I'm getting around 32 FPS in a 1600x1200 maximized window without the compositor and 7.4 FPS with the compositor. I sometimes even get interruptions in sound playback from Audacious. The compositor also causes terrible performance when scaling an Emscripten SDL 2 application which uses WebGL texture output to 1600x1200 full screen.

This is in both 35.0.1 and Nightly, 64-bit Ubuntu 14.10, KDE 4.14.1, Q6600 CPU, NVIDIA 8600GT with 331.113 proprietary drivers. The KDE compositor can be stopped and started using:
qdbus org.kde.kwin /Compositor suspend
qdbus org.kde.kwin /Compositor resume

Just posting to make sure I'm encountering this particular bug and to post the workaround.
The site mentioned in comment 4 has excellent performance for me with Firefox 39 on Ubuntu 14.04.2 LTS with a 3.16.7-based kernel, Unity 3D desktop, Core™ i7 950 CPU, AMD Radeon HD 7870 2GB with open source drivers, but other sites such as Google Maps (which now uses MapsGL by default) are still slow.

I have layers.acceleration.force-enabled set to "false" (the default).

$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.3.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
It seems like this could still be an issue. Does anyone have updated performance numbers?
Whiteboard: [gfx-noted]
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #7)
> It seems like this could still be an issue. Does anyone have updated
> performance numbers?

No, but it's known-bad, and not something that will go away accidentally.
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #7)
> It seems like this could still be an issue. Does anyone have updated
> performance numbers?

I use this WebGL demo: http://webglsamples.org/aquarium/aquarium.html

On Firefox, I get about 36 fps with stuttering (just tested with 45.0.1). On chromium I get a solid 60 fps.
(In reply to Hadrien Nilsson from comment #9)
> I use this WebGL demo: http://webglsamples.org/aquarium/aquarium.html
> 
> On Firefox, I get about 36 fps with stuttering (just tested with 45.0.1). On
> chromium I get a solid 60 fps.

Can you please test Nightly to see if there's any difference?
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #10)
> Can you please test Nightly to see if there's any difference?

About 42 fps with Nightly 48.0a1 (2016-04-01).
(In reply to Hadrien Nilsson from comment #11)
> About 42 fps with Nightly 48.0a1 (2016-04-01).

Thanks.
Just pitching in - on the aquarium demo (http://webglsamples.org/aquarium/aquarium.html), I get a high-variance FPS between 26 and 32. On Chromium, I get a more solid 54 FPS.

Output of `glxinfo | grep OpenGL`:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 950M/PCIe/SSE2
OpenGL core profile version string: 4.5.0 NVIDIA 367.57
OpenGL core profile shading language version string: 4.50 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5.0 NVIDIA 367.57
OpenGL shading language version string: 4.50 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 367.57
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

Firefox flags changed:
gfx.xrender.enabled = true
layers.acceleration.force-enabled = true
webgl.force-enabled = true

Firefox version:
51.0b10 on Ubuntu 16.10 (Linux 4.8.0-32-generic)

I'm using the proprietary NVIDIA drivers for Linux.

The issue seems to be affecting Google Maps as well, which are barely usable in Firefox but quite snappy in Chromium.
I can confirm this bug: Firefox 55 on Antergos, same flags enabled like @filiplamparski, AMDGPU for Radeon RX 580 on Linux 4.12.
In Firefox ~24 fps with 4000 fishes, 4000 fishes in Chromium with ~60 fps.
Google Maps 3D is a pain in Firefox.
I found (https://bugzilla.mozilla.org/show_bug.cgi?id=1449901) that Firefox WebGL has disproportionally low FPS (compared to Chromium) when run on high-resolution displays or when the window is dragged large:

https://bugzilla.mozilla.org/show_bug.cgi?id=1449901
See Also: → 1501684
Will WebRender solve this issue?
WebRender will not solve this.

I can confirm this issue. I am observing heavy lag with Firefox for webgl and webgl2 canvas in Linux, when the same demo has smooth performance on Chrome.

You don't notice anything on small canvases, but when showing demos or playing games in full screen (i.e. 4k/retina) the difference is extreme. This affects pretty much all PixiJS webgl2 applications as well as manual webgl demos.

Examples:

Observed with system specs:

  • OS: Linux Mint 19.1 Cinnamon (AKA Ubuntu 18.04.1 LTS) 4.15.0-50-generic x64
  • Video: NVIDIA GK104 [GeForce GTX 660 Ti] Driver: Proprietary 396.54 from Driver Manager
  • Monitor: DELL P2415Q 3840x2160
  • Firefox: Firefox Quantum 67 x64
  • Chrome: Chrome 76.0.3806.1 64-bit

Originally reported at https://github.com/pixijs/pixi.js/issues/5751

The amount of Firefox traffic is not negligible, so I'm resorting to this for full screen webgl apps:

if (~navigator.userAgent.indexOf('Linux') && ~navigator.userAgent.indexOf('Firefox')) {
    // Show section "browser not supported" and suggest Chrome

(In reply to Jeff Gilbert [:jgilbert] from comment #3)

Note that many users with recent OpenGL drivers should be able to force enable OpenGL Layers with "layers.acceleration.force-enabled".

This has no observable positive effect for me.

Depends on: wr-linux
No longer depends on: ogl-linux-beta

That's going to be addressed on Wayland by dmabuf surfaces, see Bug 1552590.

Depends on: 1552590

(In reply to Jeff Gilbert [:jgilbert] from comment #19)

WebRender will not solve this.

Some ultra naive questions to understand what is left to address this for WebRender/X11 with Mesa drivers:

(Jan Andre Ikenmeyer [:darkspirit] from comment #25)

does gfx.use-glx-texture-from-pixmap only need to be re-enabled?

It crashes.

See Also: → 1561976

Or should instead be switched to EGL on X11 to save effort and to rip out old code? (bug 788319)

  • https://en.wikipedia.org/wiki/EGL_(API)#Adoption
    "The proprietary Nvidia driver 331.13 BETA from 4 October 2013 supports the EGL API."
    "The Raspberry Pi single-board computer has an EGL interface to hardware-accelerated 3D graphics rendering." (bug 788319 comment 9)
  • Consider comparing benefits of WebGL with GLES/EGL (bug 822518) with using OpenGL/EGL (bug 1474281).
  • Broken configurations should anyway use Skia, later WebRender+SwiftShader. (bug 1548395). Skia is currently default, it shouldn't be perceived as regression.

AFAIK The bad performance is caused by GL output buffer copy between content and chrome process and that's the same for EGL and GLX. The only fix here is to render directly to GPU memory and pass that from content to chrome process (share the buffer instead of copy). That's also reason why size of the canvas matters - copy overhead is not so huge for small canvases.

This can be done by dmabuf on linux. AFAIK Chrome already uses that. Dmabuf can be implemented for both X11 and Wayland but I'm interested in Wayland implementation right now.

A status update: This bug will likely get fixed as WebRender rolls out to various linux configurations.

FYI, this bug got a lot of attention here: https://www.reddit.com/r/firefox/comments/eh6d64/webgl_gets_worse_performance_in_firefox_compared/

Really great to hear that this will get fixed along with WebRender!

This seems to be the Chrome X11 implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=1031269

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)

This seems to be the Chrome X11 implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=1031269

I think the best approach here is to switch X11 builds to EGL (Bug 788319) and share dmabuf EGL implementation with wayland. WebGL/dmabuf implementation is solved at Bug 1586696.

X11 / Wayland EGL difference should be minimal and can be covered at widget level where X11/Wayland is configured.

(In reply to Martin Stránský [:stransky] from comment #32)

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)

This seems to be the Chrome X11 implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=1031269

I think the best approach here is to switch X11 builds to EGL (Bug 788319) and share dmabuf EGL implementation with wayland. WebGL/dmabuf implementation is solved at Bug 1586696.

X11 / Wayland EGL difference should be minimal and can be covered at widget level where X11/Wayland is configured.

I agree on that. To get that going I'll try to get bug 1474281 into shape (required for Bug 788319)

This approach would also make Webrender rollout on X11 much easier, as partial damage is already being implemented for the EGL backend (e.g. bug 1484812)

Depends on: 1580166

Even with EGL on x11, I get very poor performance in aquarium test (https://webglsamples.org/aquarium/aquarium.html) . Here is the profiler report if it is useful https://share.firefox.dev/2ZFEgzo .

Some about:config entries modified:
fission.autostart true
gfx.webrender.all true
gfx.webrender.compositor true
gfx.webrender.enabled true
ayers.advanced.basic-layer.enabled true
layers.advanced.fission.enabled true
media.ffmpeg.dmabuf-textures.enabled true
media.ffmpeg.vaapi-drm-display.enabled true
media.ffmpeg.vaapi.enabled true
media.ffvpx.enabled false
webgl.enable-surface-texture true
dom.webgpu.enabled true

Also nightly 80 was launched with MOZ_X11_EGL=1

The widget.dmabuf-webgl.enabled pref has no effect on X11 yet. I think bug 1588904 should be fixed before removing the IsWaylandDisplay() restriction: https://searchfox.org/mozilla-central/rev/2f75c35b647a03e7afad0af906643ec50b5b4ede/gfx/thebes/gfxPlatformGtk.cpp#104

Depends on: 1655026
Depends on: 1658591

(In reply to Darkspirit from comment #36)

The widget.dmabuf-webgl.enabled pref has no effect on X11 yet. I think bug 1588904 should be fixed before removing the IsWaylandDisplay() restriction: https://searchfox.org/mozilla-central/rev/2f75c35b647a03e7afad0af906643ec50b5b4ede/gfx/thebes/gfxPlatformGtk.cpp#104

Now that Bug 1655026 has been resolved, nightly and chrome performance is still not comparable. For example, in webgl aquarium test, firefox drops from 60 fps to 22 at 5000 fish, while chrome stays at 60fps till 10000. At 30000 chrome is at 23-25 fps while firefox is at 5-6 fps. Is there any config that needs changing, or is it expected behaviour for now? Currently, my about config entries are as follows:

gfx.webrender.all true
gfx.webrender.compositor true
gfx.webrender.enabled true
layers.advanced.basic-layer.enabled true
media.ffmpeg.dmabuf-textures.enabled true
media.ffmpeg.vaapi-drm-display.enabled true
media.ffmpeg.vaapi.enabled true
media.ffvpx.enabled false
webgl.enable-surface-texture true
dom.webgpu.enabled true
widget.dmabuf-textures.enabled true
widget.dmabuf-webgl.enabled true

Also nightly 80 was launched with MOZ_X11_EGL=1

Please file a new bug. Open about:support, click on "Copy text to clipboard" and paste it into the attachment field:
https://bugzilla.mozilla.org/enter_bug.cgi?format=__default__&blocked=1010527&product=Core&component=Canvas%3A%20WebGL
Thanks!

(In reply to Darkspirit from comment #45)

Please file a new bug. Open about:support, click on "Copy text to clipboard" and paste it into the attachment field:
https://bugzilla.mozilla.org/enter_bug.cgi?format=__default__&blocked=1010527&product=Core&component=Canvas%3A%20WebGL
Thanks!

Created bug 1684224

Blocks: 1684224
No longer blocks: 1684224
Depends on: 1684224

@Jeff Gilbert: WebRender does not seem to solve the issue.

A report I filed which was closed as duplicate (1684592) contains a profile which was taken with WebRender enabled.

To be honest, I don't understand the issue - WebRender is OpenGL, WebGL too - why is it required to do a CPU readback at all, when a VRAM -> VRAM blit should do it?

(In reply to Clemens Eisserer from comment #49)

To be honest, I don't understand the issue - WebRender is OpenGL, WebGL too - why is it required to do a CPU readback at all, when a VRAM -> VRAM blit should do it?

WebGL is run sandboxed and thus needs a texture sharing method with WR to allow zero-copy compositing. It's basically the same problem as hardware accelerated video decoding.

There is a method on traditional X11 which allows this, but it used to be too buggy, mostly because of driver issues (bug 942302) and was thus never enabled by default. AFAIK Chrome does use it, but they also maintain a long list of driver bug workarounds - too much to handle for the FF team.

Last year texture sharing via DMABUF was finally implemented, a modern technology making it finally feasible to enable things by default. However, DMABUF sharing is very hard on GLX, which is why it's only implemented for the EGL backend. EGL is used on Wayland and we're also moving over the X11 backend to use it - see bug 1677203

So while we enable things step-by-step by default, current you need the following options:

  • Webrender enabled (gfx.webrender.all)
  • Use either the Wayland or X11/EGL backend (enabled by env vars MOZ_ENABLE_WAYLAND=1 or MOZ_X11_EGL=1)
  • make sure widget.dmabuf-webgl.enabled is enabled (should be)

I hope we'll be able to role all of these things out over the next couple of releases.

Further more, the proprietary NVIDIA driver does not yet implement DMABUF - but there appears to be an internal driver version which does, their devs already open MRs based on it (https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587). So they apparently plan to role it out soonish.

Even wirh webrender, EGL and dmabuf all enabled, performance is still not at par with chrome. Bug 1684224

(In reply to Leo_sk from comment #51)

Even wirh webrender, EGL and dmabuf all enabled, performance is still not at par with chrome. Bug 1684224

Yes, in specific cases. But that's AFAIK not a Linux issue (the site is known to be slow on FF/Windows as well) and, most importantly, has nothing to do with the general slowness triggered by readbacks. I.E. that bug shouldn't block this one - just waiting for Jeff to move it to the correct component (I guess the FF WebGL implementation or spidermonkey).

P.S. to make it even more clear: the benchmark in this bug is not Chrome, but FF on Windows/MacOS.

No longer depends on: 1684224

Someone has made some benchmarks:
https://linuxreviews.org/Firefox_Is_Making_WebRender_The_Default_Rendering_Engine_On_Linux_This_Month_And_There_Is_A_Facelift_Coming_In_May
https://linuxreviews.org/HOWTO_Make_Mozilla_Firefox_Blazing_Fast_On_Linux
EGL/Dmabuf seems to have a huge positive impact for "AMD Athlon 5350 APU".

This bug will be fixed for

Depends on: linux-egl, wr-linux-xwayland, wayland-nightly
See Also: → 1684224

We're shipping the EGL backend with activated DMABUF fast path in 94 for a big group of our users, likely even the majority. The remaining bits of this bug (activating those paths on more hardware by default) are thus tracked in bug 788319 and bug 1572697. Closing this as it's not needed any more to track anything.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
See Also: → 1749972
See Also: 1749972 →
See Also: → 1735929
You need to log in before you can comment on or make changes to this bug.