All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=647761

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg2YvroAoM


Bot(s) for this bug's original alert(s):

android-nexus5X

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9001337474909907856

i'm not sure if 5X has hardware vp9 support.  if not, then we'd fall back to libvpx.

it doesn't have hw decode, so libvpx roll seems like a likely culrpit +fgalligan, jzern.

There were a few NEON changes in that roll which improved decode performance overall in my testing outside of chrome. The 2 rolls before that had more actually. These were meant to reduce the gap in performance between 32-bit and 64-bit builds. The earlier rolls may have contributed to the dips around 8/18 and 8/19.
I'll probably be able to double check the numbers from that range sometime next week.

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@418989  15.6289  0.242151  5  good
chromium@418995  13.9913  0.154625  5  bad
chromium@419000  14.2605  0.171919  5  bad
chromium@419011  14.9926  0.298628  5  bad

Bisect job ran on: android_nexus5X_perf_bisect
Bug ID: 647761

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests media.android.tough_video_cases
Test Metric: application_energy_consumption_mwh/video.html?src_tulip2.vp9.webm
Relative Change: 4.07%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/679
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9001337474909907856


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5841103566143488

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Assign to jzern@chromium.org to check the latest libvpx roll.

Taken together f7cbfed and 4916515 show ~2% decode performance improvement at 1080p using clang from r11c on an n6p targeting arm64. I'll verify the behavior on n5x, but is it possible to run this benchmark locally with a custom tree? I'm assuming the n5x is using a 64-bit build otherwise the synced code wouldn't be hit.
If someone wanted to try to revert the changes individually it might help narrow things down. I'd start with f7cbfed.

bee7d83 Update NEON transpose functions.
3dfba04 Merge "Update vpx_lpf_vertical_16_dual_neon() intrinsics"
f7cbfed Update vpx_lpf_vertical_16_dual_neon() intrinsics
3a3169b Merge "Update vpx_lpf_horizontal_edge_16_neon() intrinsics"
4916515 Update vpx_lpf_horizontal_edge_16_neon() intrinsics

To run it locally you can build and install chrome_public_apk. And then use a command like:

tools/perf/run_benchmark -v --browser=android-chromium --also-run-disabled-tests --story-filter tulip2.vp9.webm media.android.tough_video_cases

Thanks for the info, I'll give that a try when I get a chance. For the record the n5x performs similar to the n6p.

I can confirm this on a n5x, but am inclined to leave things as is for now as the set of changes did have a positive impact on decode performance and overall we're still net positive going from >17mWh to ~16 now. This will be interesting to continue to track if/when we switch to using the high bitdepth decoder and when this build switches to clang.