New issue
Advanced search Search tips

Issue 590796 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

28.3% regression in media.tough_video_cases at 375690:375751

Project Member Reported by jrumm...@chromium.org, Feb 29 2016

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=590796

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


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

chromium-rel-mac-hdd
Cc: dcasta...@chromium.org
Owner: dcasta...@chromium.org

=== Auto-CCing suspected CL author dcastagna@chromium.org ===

Hi dcastagna@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Reland: Enable NV12 VideoFrames on Mac.
Author  : dcastagna
Commit description:
  
As described in  crbug.com/524582 , we observed a reduction in power
consumption when this format is used to display videos directly using
the WindowServer.

The downside of this format is that a conversion from YUV to RGB will
be performed on the GPU using GL when the VideoFrame has to be used
from GL.

BUG= 524582 

Review URL: https://codereview.chromium.org/1686443002

Cr-Commit-Position: refs/heads/master@{#375720}
Commit  : 30f1ed90fef395aab3d991feaef5af86235bf235
Date    : Wed Feb 17 00:17:53 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@375689         1215.4      6.387488    5           good
chromium@375705         1190.6      7.436397    5           good
chromium@375714         1223.0      23.366643   5           good
chromium@375719         1211.6      18.091434   5           good
chromium@375720         1569.4      48.345631   5           bad
chromium@375721         1613.8      67.747325   5           bad
chromium@375723         1528.0      98.407317   5           bad
chromium@375751         1598.8      51.732002   5           bad

Bisect job ran on: mac_hdd_perf_bisect
Bug ID: 590796

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests media.tough_video_cases
Test Metric: idle_wakeups_gpu/idle_wakeups_gpu
Relative Change: 31.55%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_hdd_perf_bisect/builds/425
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9019459254673881152


| 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 label Cr-Tests-AutoBisect.  Thank you!

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Reland: Enable NV12 VideoFrames on Mac.
Author  : dcastagna
Commit description:
  
As described in  crbug.com/524582 , we observed a reduction in power
consumption when this format is used to display videos directly using
the WindowServer.

The downside of this format is that a conversion from YUV to RGB will
be performed on the GPU using GL when the VideoFrame has to be used
from GL.

BUG= 524582 

Review URL: https://codereview.chromium.org/1686443002

Cr-Commit-Position: refs/heads/master@{#375720}
Commit  : 30f1ed90fef395aab3d991feaef5af86235bf235
Date    : Wed Feb 17 00:17:53 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@375689         1217.555556 110.756873  18          good
chromium@375705         1225.888889 67.072295   18          good
chromium@375714         1237.388889 58.991663   18          good
chromium@375719         1248.611111 22.981166   18          good
chromium@375720         1515.6      41.301332   5           bad
chromium@375721         1507.833333 197.439903  12          bad
chromium@375723         1534.055556 217.918083  18          bad
chromium@375751         1577.083333 114.860752  12          bad

Bisect job ran on: mac_hdd_perf_bisect
Bug ID: 590796

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests media.tough_video_cases
Test Metric: idle_wakeups_gpu/idle_wakeups_gpu
Relative Change: 20.94%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_hdd_perf_bisect/builds/426
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9019459240438505376


| 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 label Cr-Tests-AutoBisect.  Thank you!
Project Member

Comment 4 by 42576172...@developer.gserviceaccount.com, Mar 12 2016


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Reland: Enable NV12 VideoFrames on Mac.
Author  : dcastagna
Commit description:
  
As described in  crbug.com/524582 , we observed a reduction in power
consumption when this format is used to display videos directly using
the WindowServer.

The downside of this format is that a conversion from YUV to RGB will
be performed on the GPU using GL when the VideoFrame has to be used
from GL.

BUG= 524582 

Review URL: https://codereview.chromium.org/1686443002

Cr-Commit-Position: refs/heads/master@{#375720}
Commit  : 30f1ed90fef395aab3d991feaef5af86235bf235
Date    : Wed Feb 17 00:17:53 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@375610         2047.166667 133.915521  6           good
chromium@375704         1850.375    181.054007  8           good
chromium@375714         1915.142857 120.5991    7           good
chromium@375718         2038.125    168.297727  8           good
chromium@375719         1862.4      243.315228  5           good
chromium@375720         2358.5      175.149732  8           bad
chromium@375721         2500.5      127.630326  6           bad
chromium@375728         2469.8      135.643651  5           bad
chromium@375751         2354.333333 228.521042  6           bad
chromium@375790         2446.0      157.918605  8           bad

Bisect job ran on: mac_hdd_perf_bisect
Bug ID: 590796

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --also-run-disabled-tests media.tough_video_cases
Test Metric: idle_wakeups_total/idle_wakeups_total
Relative Change: 17.04%
Score: 99.5

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_hdd_perf_bisect/builds/447
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9018488209557415104


| 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 label Cr-Tests-AutoBisect.  Thank you!
Cc: ccameron@chromium.org
Labels: OS-Mac
Tracing before and after this change I see that GLES2DecoderImpl::DoReleaseTexImage2DCHROMIUM/GLES2DecoderImpl::DoBindTexImage2DCHROMIUM happens once per frame with UYVY while it seems to happen three times with NV12.

This is not what I expected, since VideoFrame contains only one texture/mailbox in both cases.
A wild guess is that DelegatingRenderer::DrawFrame is causing the three release/bind.
ccameron@: do you know if that can be the case? Is it expected to have more release/bind for NV12 than for UYVY?

I attached the two traces in case they can be useful.
trace_uyvyvf.json.gz
2.1 MB Download
trace_nv12vf.json.gz
3.0 MB Download
It may be that we're somehow hitting more calls to CGLTexImageIOSurface2D than we want to (that call is expensive -- see  issue 562222 ). I can take a look in the next new days.
ccameron, any updates here?
Cc: nyerramilli@chromium.org
Labels: TE-Triaged
gentle ping..
I'll try to investigate this further this week.

I wouldn't be worried too much about the regression though. The idle_wakeup metrics are tracked to avoid power regressions while after crrev.com/1686443002 we had an overall noticeable reduction in power consumption.
So idle wakeups went up, but power consumption went down? What metrics were you looking at for power consumption?
dcastagna@

Could you reply to #10?

Also, As of the latest datapoints for the graphs linked to this bug, there seems to be a partial recovery.
Labels: Needs-Feedback
ccameron@ has some data about power consumption over different versions that show power improvements when we enabled this format.

We also changed the code that does the format conversion in the GPU process lately, that might be what you noticed as partial recovery.

ccameron@, do you think we should spend more time investigating or should we mark it as won't fix given the power improvements?
If it's legitimately a decrease in power, we shouldn't worry about idle wakeups going up. Verifying with a BattOr would be the ideal way to prove this.
Friendly sheriff ping,
dcastagna@chromium.org, Could you please reply to #14
Status: WontFix (was: Assigned)
We've verified a substantial power decrease (and ability to enter detached mode, among other things). Let's close as WillNotFix.

Sign in to add a comment