1562433 - Very high CPU utilization from pulsating animation

Status: NEW

(Core :: Graphics, defect, P2)

Description

[Kenny Levinsen :kennylevinsen]

Attachment: Pulsating SVG arrow

The webpage "https://ampl.fi/" has a very high CPU utilization on my machine (ultrabook, nightly 2019-06-14), going up to ~160% with WebRender, ~50% with basic compositor.

This is all stemming from a set of CSS animations being run: A pulsating SVG arrow, and the moving music notes. Killing these DOM nodes drops CPU utilization to 9%.

I have isolated and attached one of the animations (the pulsating SVG arrow) for easy reproduction, which by itself causes around 50-70% CPU utilizations with WebRender, and around 20-30% utilization with the basic compositor.

WebRender is obviously far more troublesome here, but basic is also burning a lot.

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

I collected some profiles from your test case but could not reproduce the high CPU case. Could you collect a profile using https://profiler.firefox.com/? Before capturing a profile for WebRender, please ensure the custom threads box is "GeckoMain,Compositor,RenderBackend,Renderer,WR" so that we capture the threads we need. Thanks!

Comment 2

[Kenny Levinsen :kennylevinsen]

Attachment: Profile of ampl.fi

Comment 3

[Kenny Levinsen :kennylevinsen]

Attachment: Profile of pulsating svg reproduction

Comment 4

[Kenny Levinsen :kennylevinsen]

Attachment: htop/ampl.fi screenshot showing consumption

Comment 5

[Kenny Levinsen :kennylevinsen]

Attachment: htop/test.html screenshot showing consumption

Comment 6

[Kenny Levinsen :kennylevinsen]

Attachment: htop/profiler.firefox.com screenshot showing idle usage

Comment 7

[Kenny Levinsen :kennylevinsen]

I have attached profiles from my nightly install, and some screenshots showing the high CPU usage + idle usage on profiler.firefox.com.

Notes:

• I am running under Wayland on Linux (using sway), although I doubt that is a large contributor here.
• I am running on an ultrabook, which greatly amplifies any performance issues compared to a desktop.

Just ask if there are any other measurements you would like.

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

It seems to be spending most of its time outside the DRI driver, so presumably this isn't Linux specific (please reduce to P3 if it looks to be NVIDIA + Linux specific). Anything jump out at you from the WR side Glenn? I notice the reduced test case it is mostly just rendering frames, not a lot of display list activity, but for the full page, we appear to regenerate the display list each time.

Comment 9

[Kenny Levinsen :kennylevinsen]

(please reduce to P3 if it looks to be NVIDIA + Linux specific)

Just to clarify, the test machine is Certified NVIDIA Free (TM) for the preservation of your sanity. It's a Dell XPS 13 9370, using the UHD Graphics 620 on-board its i7-8550U.

Comment 10

[Glenn Watson [:gw]]

There's nothing really obvious in the WR profile that stands out to me from a quick look. It does seem like the WR worker threads are active quite a lot - maybe there is something going wrong in blob rasterization? Nical, any ideas?

Comment 11

[Nicolas Silva [:nical]]

From a quick profile of the pulsating arrow testcase, most of the time is spent in frame building. This is an area where WebRender does a lot more work than the compositor backends when there's only an async animation changing. The combination of document splitting (per-document) picture caching will certainly help but as long as we re-do all of the frame building work each frame webrender will use more CPU than the compositor backends.
The worker threads are not doing anything in that testcase for me (I haven't profiled the website yet).

Comment 12

[Nicolas Silva [:nical]]

On the ampl.fi website:

• We don't quite rebuild the scene every frame, but we re-build it a lot.
• On my laptop the render backend thread is awake 20% of the time according to the gecko profiler which is a bit high. On average frame building is taking 3ms but the maximum frame build per 500ms slice stays around 9ms which is high. The first frame after scene building is probably consistently expensive. on average we the time spent on the render backend looks like what we are used to: a good chunk of the time in build_layer_screen_rects_and_cull_layers and some amount in RenderPass::build (add_prim_to_batch mostly).
• The renderer thread is very busy (that may vary depending on the configurations, though). Pretty much 100% awake submitting draw calls even though there is only between 50 and 60 of them. 50% in draw_color_target, 25% in draw_clip_batch (all of the time in the previous two are spent in glDrawElementsInstanced) and 25% in something that calls bind_texture.
• On the GPU side we also spend quite a bit more time than I'd like. a quarter of the frames are around 15ms and the rest around 7ms, and there's this repeated pattern of a bunch of 15ms frames then a bunch of 7ms frames which I suppose also correlates with scene builds. The GPU time is spent mostly in blend, solid and image shaders.

My take is that we are still not very good at incremental computation in webrender and re-do a lot more than we should when there are scene builds, and more generally each frame.