Open Bug 1010527 (slow-linux-webgl) Opened 6 years ago Updated 13 days ago

WebGL composites slowly on Linux by default

Categories

(Core :: Canvas: WebGL, defect, P3)

All
Linux
defect

Tracking

()

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.
Duplicate of this bug: 997156
Duplicate of this bug: 1010232
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:
Duplicate of this bug: 1256188
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.
Duplicate of this bug: 716121
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
Duplicate of this bug: 1449901
See Also: → 1501684
Will WebRender solve this issue?
WebRender will not solve this.
Duplicate of this bug: 1501684
Duplicate of this bug: 669206
Duplicate of this bug: 1404701

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.

(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.

You need to log in before you can comment on or make changes to this bug.