1455346 - https://www.inc.com/30-under-30 has a lot of gpu time

Status: RESOLVED INVALID

(Core :: Graphics: WebRender, enhancement, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

I see 14ms in the middle of the page.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

We should find out what this is before we decide on the urgency

Comment 2

[Jeff Muizelaar [:jrmuizel]]

I put up a rough stand alone copy at https://jrmuizel.github.io/webrender/meet.html

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: Screenshot of the part of the page showing the problem

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Glenn, any thoughts on what might be going on here?

Comment 5

[Glenn Watson [:gw]]

Looks like there are at least a few things going on here:

- 5 alpha targets are allocated, almost all for clip masks. But the vast majority of these seem to be redundant.
- We're not yet caching those clips masks either, so we pay the cost for that redundancy every frame.
- There are some very expensive image and blend blits - 3 full size color targets are allocated.
- My guess is that these are hitting the slow opacity path needlessly (there is an existing WR bug for this).
- Even if they're running more expensive filters, we should be caching those.
- There is a ridiculously high primitive count in the middle of the page - ~1400 visible primitives where there are seemingly just a few images, < 10 text runs, and a few buttons. Perhaps there are a huge number of overlays or something like that, which we can eliminate / cache in one rendered target.

This is a good test case, thanks!

Comment 6

[Glenn Watson [:gw]]

I'll paste more detailed info here once I run it through a GPU profiler and confirm some of those theories above.

Comment 7

[Glenn Watson [:gw]]

<div id="5ad4c30efcd52" class="component page-object image" style="position: absolute; width: 1300px; height: 557px; display: block; cursor: inherit; z-index: 78; left: 0px; top: 1624px; transform: translate(0px, 0px) rotate(0deg) scale(1, 1); opacity: 0.93;" data-container-id="5abe9ac313f7e"><img style="display: block; border-width: 0px; box-shadow: none;" src="rising-stars-desktop-final_data/slide3-separated-adelle-full.png" width="1300" height="557"></div>

This node contains an image 2600 x 1114, with an opacity filter 0.93. It's then repeated 4 times directly after one another in the HTML, which seems very odd. So that's a large number of full-screen opacity blits.

We'll get some big wins here by:

 * Caching opacity filters (and we'll detect that the same image/filter is repeated four times and skip doing that work).
 * Optimizing the opacity filter (it currently runs through the expensive blend shader, should be using hardware opacity).
 * Having a fast path for opacity filters that contain a single image (element) by just drawing them directly with a color scale (this would actually be optimal, and mean the above caching changes don't apply in this case).

Comment 8

[Glenn Watson [:gw]]

I opened a PR for collapsing simple opacity filters: https://github.com/servo/webrender/pull/2680.

This drops the GPU time on that part of the page from ~14ms to ~9ms on my local machine.

There's still work to be done on the redundant clip mask generation, and the large image overdraw, but this is a start.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Tentatively moving to Dan.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

I'll check how this looks on Nvidia hardware

Comment 11

[Jeff Muizelaar [:jrmuizel]]

This seems good enough on Nvidia hardware. Not blocking release.

Comment 12

[u480271]

Unassigning myself to allow others to pick this up.

Comment 13

[Nicolas Silva [:nical]]

The page is gone and I beleive we have other bugs on file about the issues described int his one. Closing.