1476368 - https://old.reddit.com/r/nier/ does not run smoothly at 120fps

Status: NEW

(Core :: Graphics: WebRender, defect, P5)

Description

[pnm79623]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180713213322

Steps to reproduce:

Open https://old.reddit.com/r/nier/
When page finishes loading scrolling becomes consistently choppy.
If animation is blocked, scrolling becomes normal again.


Actual results:

Pages with complex animations that use transparency degrade scrolling performance when using WebRender.


Expected results:

Scrolling is smooth like when using Direct3D 11 Advanced Layers Compositing.

Comment 1

[pnm79623]

Attachment: Video demonstration

Video demonstration, first half WebRender OFF second half WebRender ON.

Comment 2

[Darkspirit]

Could you please open about:support, click on the "Copy text to clipboard" button, paste it into a text file and upload it here (Attach File)? Thanks!

Comment 3

[pnm79623]

Attachment: Troubleshooting Information

Comment 4

[Jeff Muizelaar [:jrmuizel]]

This seems to run well for me on Mac. I'll try it on Windows.

Comment 5

[pnm79623]

Attachment: video with gfx.webrender.debug.profiler=true

Comment 6

[Jeff Muizelaar [:jrmuizel]]

What's the refresh rate of you monitor? Can you also turn on gfx.webrender.debug.gpu-time-queries and gfx.webrender.debug.gpu-sample-queries?

Comment 7

[pnm79623]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)
> What's the refresh rate of you monitor? Can you also turn on
> gfx.webrender.debug.gpu-time-queries and
> gfx.webrender.debug.gpu-sample-queries?

Native 120Hz display. Attaching new video.

Comment 8

[pnm79623]

Attachment: gpu-time / gpu-sample-queries

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Great. It looks like we might be bottlenecked on the CPU side. Can you attach another video that has layers.acceleration.draw-fps  on and WebRender off?

Comment 10

[pnm79623]

Attachment: layers_acceleration_draw-fps.webm

CPU is i7-4790k@4.4 on all cores (power states/steps/saving disabled)

Comment 11

[Jeff Muizelaar [:jrmuizel]]

So I remembered that gfx.webrender.debug.gpu-time-queries and gfx.webrender.debug.gpu-sample-queries can have a big impact on performance. If you turns those off and set gfx.webrender.debug.compact-profiler=true do you get a reasonably consistent frame rate of 120fps during scrolling? If so is it still choppy even though the frame-rate says 120fps?

Comment 12

[pnm79623]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)
> So I remembered that gfx.webrender.debug.gpu-time-queries and
> gfx.webrender.debug.gpu-sample-queries can have a big impact on performance.
> If you turns those off and set gfx.webrender.debug.compact-profiler=true do
> you get a reasonably consistent frame rate of 120fps during scrolling? If so
> is it still choppy even though the frame-rate says 120fps?

With WebRender I'm getting 120FPS while "stationary". During scrolling FPS drops but rarely to double digits. You can see it in this attachment.
https://bug1476368.bmoattachments.org/attachment.cgi?id=8993540

With advanced layers FPS stays very high even during scrolling, though it still dips to 117-113 it doesn't feel weird like when WR is used.

On the other note, yesterday I tied forcing maximal performance mode in GPU for Firefox but it help at all.

Is there anything else I can do that might help?

Comment 13

[Jeff Muizelaar [:jrmuizel]]

There might be a frame rate consistency issue here. We'll try to add some better metrics to the HUD to get a better idea of what's going on.

Can you install the Gecko profiler add-on https://perf-html.io/, open the add-on and go to settings, add the following threads "RenderBackend,Renderer,WebRender,Wr" to the list and then get a profile of the scrolling slowdown?

Comment 14

[pnm79623]

Attachment: CPU usage

So I just quickly checked if anything changed in almost a month of nightly development but unfortunately even more problems appeared. CPU usage is very high on that page (4 times higher than without webrender 20% vs 5%). CPU usage drops to 0 if I close the tab or minimize Firefox.

I will test performance with that addon later.

Comment 15

[Maire Reavy [:mreavy]]

Jeff -- Have you ever reproduced this on Windows/nvidia?  Have we added metrics (ref: Comment 13)?
Reporter -- Does this still happen for you?  What driver are you using? (nvidia?  Intel? something else?)  Have you only seen it on one machine so far?

Thanks!

Comment 16

[Jeff Muizelaar [:jrmuizel]]

I still see some weird frame pacing on this profile: https://perfht.ml/2EaT6oV

Comment 17

[Jeff Muizelaar [:jrmuizel]]

https://github.com/devtools-html/perf.html/issues/1195 is also helpful for looking at this.

Comment 18

[pnm79623]

(In reply to Maire Reavy [:mreavy] Plz needinfo from comment #15)
> Jeff -- Have you ever reproduced this on Windows/nvidia?  Have we added
> metrics (ref: Comment 13)?
> Reporter -- Does this still happen for you?  What driver are you using?
> (nvidia?  Intel? something else?)  Have you only seen it on one machine so
> far?
> 
> Thanks!

This is still happening and CPU usage is relatively very high comparing to advanced layers. nVidia GTX1070, drivers 416.34, windows 10 1809

Comment 19

[Jeff Muizelaar [:jrmuizel]]

How does this look for you now?

Comment 20

[Nicolas Silva [:nical]]

This page performs poorly on my x1 carbon laptop (linux + intel). From a quick look in perf there seem to be some low hanging fruits to pick. Here' what stands out at a glance:

• The average number of retired instruction per cycle is low (usually means unhappy caches). On this CPU I usually get about 2.0 ins/cycle for instruction-bound workloads and here I'm getting 0.6.
• There's a lot of page faults happening in RenderTaskTree::add. Looks like we can't recycle the allocation because the tree is sent to the render thread but we can record the previous allocated size and pre-allocate the vectors each frame (*).
• A lot of instruction cache misses on the render thread in driver code and in draw_instanced_batch. Dzmitry's suggestion to remove redundant gl calls might help here (Edit: I got mixed up, the suggestion was in another bug).
• PrimitiveStore::update_visibility is is high in number of samples and also in the number of data cache misses. This one might not be a low hanging fruit but I'm pointing it out because this function consistently shows up at the top of profiles for me lately.

(*): Actually, even though we send the RenderTaskTree to the renderer it looks like we only use it there for debugging purposes ... aaand no we do use it for non-debug things as well.

Comment 21

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Preallocate the render task tree. r=kvark

Comment 22

[Nicolas Silva [:nical]]

On a machine with a more powerful CPU and a 4k screen the biggest problem is GPU times with lots of time spent in B_Blend.
(Edit: I had picture caching disabled, my bad, it does wonders on this page).

On the CPU side it clearly doesn't help that the banner at the top has a css animation on background-position which is causing us to continuously go through DL building, scene building, frame building and rendering even when it is off-screen.

Optimizations will help but the best way to really cut CPU times for this type of pages is to add support for more animated properties.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b7ad79d07c44
Preallocate the render task tree. r=kvark

Comment 24

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b7ad79d07c44

Comment 25

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Preallocate a few more items in the render task tree. r=kvark

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/df0e32716df1
Preallocate a few more items in the render task tree. r=kvark

Comment 27

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Pre-allocate vectors in HitTester::read_clip_scroll_tree. r=kvark

Comment 28

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Pre-allocate primitives vector in setup_picture_caching. r=gw

Comment 29

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Avoid moving texture cache entries when evicting them. r=gw

Comment 30

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Reserve storage for the dynamic property vectors in the bindings before filling them. r=kvark

Comment 31

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Avoid moving picture primitives when destroying them. r=gw

Comment 32

[Nicolas Silva [:nical]]

Attachment: Bug 1476368 - Add VecHelper::take/take_and_preallocate. r=gw

Comment 33

[Nicolas Silva [:nical]]

Here is a series of small changes in a general attempt to reduce the __memmove_avx_unaligned_erms samples that were towards the top of the profile and consolidated into a single group. Perf wouldn't give me the stacks for these samples unfortunately, so I resorted to gdb breakpoints to figuring where a lot of these memmoves come from.

Removing some of the memmoves might not yield real perf wins if the time was mostly spent waiting for cold misses (the read will still happen), but if anything these patches reduce the amount of perf samples that fall into the __memmove_avx_unaligned_erms bucket and the potential cache misses move into hopefully more helpful symbols. Also the changes are generally trivial.

One of the most notable source of frequent small __memmove_avx_unaligned_erms on the render backend comes from moving TransformUpdateState in ClipScrollTree::update_tree. It isn't as straighforward to reduce as the first wave of changes, though.

Another thing that came up while profiling this page is the cost of moving/hashing/cloning FontInstace, but that required more involved surgery so I filed bug 1529272 for that.

Comment 34

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/df0e32716df1

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b512bb508796
Pre-allocate vectors in HitTester::read_clip_scroll_tree. r=kvark
https://hg.mozilla.org/integration/mozilla-inbound/rev/932ab91a896e
Pre-allocate primitives vector in setup_picture_caching. r=gw
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0c93c9acd66
Avoid moving texture cache entries when evicting them. r=gw
https://hg.mozilla.org/integration/mozilla-inbound/rev/659354cec17d
Reserve storage for the dynamic property vectors in the bindings before filling them. r=kvark
https://hg.mozilla.org/integration/mozilla-inbound/rev/9af23e1d86c8
Avoid moving picture primitives when destroying them. r=gw
https://hg.mozilla.org/integration/mozilla-inbound/rev/7102801e2ca8
Add VecHelper::take/take_and_preallocate. r=gw

Comment 36

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/b512bb508796
https://hg.mozilla.org/mozilla-central/rev/932ab91a896e
https://hg.mozilla.org/mozilla-central/rev/d0c93c9acd66
https://hg.mozilla.org/mozilla-central/rev/659354cec17d
https://hg.mozilla.org/mozilla-central/rev/9af23e1d86c8
https://hg.mozilla.org/mozilla-central/rev/7102801e2ca8

Comment 37

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Comment 38

[Jessie [:jbonisteel] pls NI]

We can leave it open for now

Comment 39

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Comment 40

[Jessie [:jbonisteel] pls NI]

Does this still need to be left open, Nical?

Comment 41

[Nicolas Silva [:nical]]

Performance isn't great but not aweful on this page these days. I don't have a way to test at 120fps, though. We could leave it open and revisite when progress is made on the two dependencies.

Comment 42

[Release mgmt bot [:sylvestre / :calixte / :marco for bugbug]]

The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?