Open Bug 1416652 Opened 2 years ago Updated 4 months ago

Bad performance on running tsvgx talos suite

Categories

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

x86_64
All
defect

Tracking

()

Tracking Status
firefox57 --- unaffected
firefox58 --- unaffected
firefox69 --- affected
firefox70 --- affected

People

(Reporter: vliu, Assigned: mattwoodrow)

References

(Blocks 3 open bugs)

Details

(Whiteboard: [wr-reserve] [gfx-noted][needs-investigation])

See [1] and [2] for the Comparison link in detail. They showed that

tsvgx opt e10s in Linux x64 opt: 60.61%
tsvgx opt e10s stylo_disabled in Linux x64 opt: 59.48%

tsvgx opt e10s in Windows 10 x64 opt: 322.49%
tsvgx opt e10s stylo_disabled in Windows 10 x64 opt: 288.54%


[1]: Comparison link on Linux x64 opt
     https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=226893bbeb3e&newProject=try&newRevision=624d8ef848c2d76eed6a2854e03e3c54950ffd12&framework=1
[2]: Comparison link on Windows 10 x64 opt
     https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=e20b42426413&newProject=try&newRevision=ec5b6c878d2abaf1c98a5cdc1284fd38625f1822&framework=1
Blocks: 1416635
Whiteboard: [wr-mvp] [triage]
Whiteboard: [wr-mvp] [triage] → [wr-mvp]
Depends on: 1416995
Whiteboard: [wr-mvp] → [wr-mvp] [gfx-noted]
Depends on: 1418869
Assignee: nobody → ethlin
Status: NEW → ASSIGNED
Priority: P2 → P1
I think we should measure talos with non-blobimage for now, since blobimage haven't been turned on by default.
(In reply to Ethan Lin[:ethlin] from comment #2)
> I think we should measure talos with non-blobimage for now, since blobimage
> haven't been turned on by default.

I tried to rebase with today's code base and created another comparison for tsvgx talos. It still worse than disabling wr. But even so, it becomes better when I measured it at the first time on 2017-11-12.

linux64: 21.30%
windows10-64: 49.53%

linux64: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=27124062459e&newProject=try&newRevision=6344d84dbfeff7fb75aa6da33980b9cd119e56be&framework=1
windows10-64: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=8cc7ccdb5c91&newProject=try&newRevision=6ca9d9eb44e5b2ac51c5ba5c6c7d6e049600d219&framework=1
From comment 1 and comment 3, svg fallback is 3 times better than svg with blob image on.
I will lower the priority because we havn't turn blob image on by default.

[WR with blob image on] 
linux64[1]: tsvgx opt e10s: 73.65%
Windows 10 x64: tsvgx opt e10s: 195.25%

[WR with blob image off]
linux64: 21.30%
windows10-64: 49.53%
Assignee: ethlin → nobody
Status: ASSIGNED → NEW
Priority: P1 → P3
Whiteboard: [wr-mvp] [gfx-noted] → [wr-reserve] [gfx-noted]
https://treeherder.mozilla.org/perf.html#/graphs?series=autoland,1646629,1,1&series=autoland,1683595,1,1&series=autoland,1651299,1,1&series=autoland,1686440,1,1

Linux and Windows are both worse with WR enabled than disabled. Bumping to P1 for windows regression.
Blocks: stage-wr-trains
No longer blocks: stage-wr-nightly
OS: Unspecified → All
Priority: P3 → P1
Hardware: Unspecified → x86_64
As of bug 1476636/bug 1455422 landing, this got worse on both Linux and Windows.
Blocks: 1476636
Depends on: 1477638
We can't release this to the field, but we can let this ride to beta.  However, we want to investigate and understand the bad perf numbers asap.
Priority: P1 → P2
Whiteboard: [wr-reserve] [gfx-noted] → [wr-reserve] [gfx-noted][needs-investigation]
Priority: P2 → P3
Priority: P3 → P2
Assignee: nobody → matt.woodrow
I had a look at some of the subtests, and what we might be able to do to improve scores on them:

hixie-001.xml:
hixie-002.xml:

Moves a circle around on top of a complex SVG image. Animation is done from JS, and modifies the cx/cy attributes on an SVG circle element. It also updates text at the bottom of the SVG show how many frames of the animation have been presented.

Since we only use a single dirty rect, we end up invalidating the union of the new/old circle areas and the text, which is a pretty large area of the image.

Switching to a region for dirty areas would help a lot here.

We could also try teaching the grouping code to know to put the circle into a separate blob, but that's pretty complex FLB-like  logic that we to avoid if possible.

The second subtest is the same as the first, except the circle is partially transparent (using the fill-opacity attribute).


hixie-003.xml:

Regression is relatively minor, not investigated.

hixie-004.xml:

Adds scaled and transformed images to the scene each frame. Dirty rect covers most of the SVG most frame, and it doesn't look like we could do a whole lot better here.

We add two images per frame, and currently we repaint tiles fully if they intersect the dirty rect, so on some frames have a dirty region, and dirty-per-tile might help.

We could also try promoting simple SVG images to real WebRender display items, and composite them on the GPU. That'd be a huge win here, since it's the same image every time (and we'd only need to upload it once). It's unclear how well this correlates to real world usage of SVGs though.

hixie-005.xml:
hixie-006.xml:

These are both the same as 4, except using a linear or radial gradient instead of an image.

hixie-007.xml:

Performance win for WR on this subtest.
The other alternative is just to use Direct2D for blob rasterization, as the extra speed would probably make these issues irrelevant.

I think we want to avoid doing that if possible though.
tsvgx isn't something that we need to optimize for we can ship with this.
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Blocks: 1505290
You need to log in before you can comment on or make changes to this bug.