1269524 - 3.53 - 6.24% tcanvasmark (windows7-32, windowsxp) regression on push 146b55a0222202b6eb98f0ead305776d8ae0fc2b (Thu Apr 28 2016)

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[William Lachance (:wlach)]

Talos has detected a Firefox performance regression from push 146b55a0222202b6eb98f0ead305776d8ae0fc2b. As author of one of the patches included in that push, we need your help to address this regression.

This is a list of all known regressions and improvements related to the push:

https://treeherder.mozilla.org/perf.html#/alerts?id=1053

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see:

https://wiki.mozilla.org/Buildbot/Talos/Tests#CanvasMark

Reproducing and debugging the regression:

If you would like to re-run this Talos test on a potential fix, use try with the following syntax:

try: -b o -p win32 -u none -t chromez[Windows XP,Windows 7],chromez-e10s[Windows XP,Windows 7] --rebuild 5  # add "mozharness: --spsProfile" to generate profile data

(we suggest --rebuild 5 to be more confident in the results)

To run the test locally and do a more in-depth investigation, first set up a local Talos environment:

https://wiki.mozilla.lorg/Buildbot/Talos/Running#Running_locally_-_Source_Code

Then run the following command from the directory where you set up Talos:

talos --develop -e [path]/firefox -a tcanvasmark

(add --e10s to run tests in e10s mode)

Making a decision:

As the patch author we need your feedback to help us handle this regression.
*** Please let us know your plans by Thursday, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:

https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling

Comment 1

[Lee Salzman [:lsalzman]]

I am investigating if the source of this regression can be found. From circumstantial evidence, since it only seems to affect strongly 32 bit builds (but not 64 bit) and since Skia has slowly been moving away from runtime detection of SSE2 support, I believe that it is some upstream development thereof.

In any event, we are willing to accept the regression if no smoking gun can be found, as it is important to keep up to date with Skia upstream to prevent significant divergence.

Also to be taken into consideration is that I recently boosted canvasmark numbers significantly such that even with this small regression we're still ahead overall.

Comment 2

[William Lachance (:wlach)]

Ok, let's leave this open for now. Feel free to resolve as wontfix if you can't find the root cause, at your discretion.

Comment 3

[Lee Salzman [:lsalzman]]

Attachment: implement blit_row_s32a_opaque in Skia SkOpts_sse2

This doesn't fix the regression here seemingly, but I did coincidentally find a new missing handler for blending transparent sources. The reason it probably did not affect talos results is because there is a handler implemented in SkOpts_sse41. This would only affect machines that do not have SSE 4.1 but do have SSE 2.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0ffec562285b

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0ffec562285b

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

checking the graphs, I can confirm this doesn't fix the regression- no surprises!

Comment 7

[Lee Salzman [:lsalzman]]

It doesn't seem like there's an easy resolution to this with respect to SSE2, so I am marking this as wontfix.

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

thanks for getting to a resolution here.

Comment 9

[Firefox Bug Husbandry Bot]

Removing leave-open keyword from resolved bugs, per :sylvestre.