New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 741760 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 19
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

16.9% regression in media.tough_video_cases_tbmv2 at 485231:485300

Project Member Reported by zhanliang@google.com, Jul 12 2017

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Jul 12 2017

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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=0cfc3dd6c973ca4166325e93ba01e583f12b8c309605875392b5734e92f4480a


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

chromium-rel-win8-dual
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Jul 12 2017

Cc: capn@google.com
Owner: capn@google.com

=== Auto-CCing suspected CL author capn@google.com ===

Hi capn@google.com, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Nicolas Capens
  Commit : e3a8263c6440700f8eb91b3c00b844784c3665cc
  Date   : Mon Jul 10 16:13:50 2017
  Subject: Roll SwiftShader 83a6bb9..a781af7

Bisect Details
  Configuration: win_8_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : memory:chrome:gpu_process:reported_by_os:proportional_resident_size_avg/video.html?src_garden2_10s.mp4
  Change       : 15.26% | 15875065.5 -> 18298223.3333

Revision             Result                   N
chromium@485230      15875066 +- 78313.9      6      good
chromium@485265      15917601 +- 61728.3      6      good
chromium@485283      15853271 +- 78126.5      6      good
chromium@485285      15920983 +- 66596.3      6      good
chromium@485286      18404186 +- 67856.3      6      bad       <--
chromium@485288      18408881 +- 71895.2      6      bad
chromium@485292      18327897 +- 58940.5      6      bad
chromium@485300      18298223 +- 60970.3      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.garden2.10s.mp4 media.tough_video_cases_tbmv2

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8974254511226573984


For feedback, file a bug with component Speed>Bisection
Project Member

Comment 4 by 42576172...@developer.gserviceaccount.com, Jul 13 2017

 Issue 741919  has been merged into this issue.

Comment 5 by capn@chromium.org, Jul 13 2017

Cc: sugoi@chromium.org
Status: Assigned (was: Untriaged)
Interesting. We discussed potential performance implications at https://swiftshader-review.googlesource.com/10431, but not memory consumption. What appears to happen is that clearing these buffers commits them to RAM before drawing anything with WebGL, which causes a delta for this test because it was never using WebGL anyway.

When we first enabled SwiftShader, which caused the GPU process to be launched by tests like these even though they don't use it, we got a similar regression report for time to first frame performance ( Issue 702417 ). So I could mark this as a duplicate.

Alternatively we could be more selective in the buffers we clear.  Issue 737875  was only for one specific buffer but we decided to clear them all for good measure. But being more selective could cause that issue to reappear elsewhere so I'd rather not do that.

Yet another solution would be to clear (or even allocate) the buffers on first use. While this requires checking for it at every draw operation, we already check for certain things that need updating anyway, so I can probably do it at that time.
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 13 2017

Labels: Hotlist-Google

Comment 7 by capn@chromium.org, Jul 13 2017

Actually, we already only call Renderer::initializeThreads() at the first draw call. So I'm not sure any more how this could have resulted in an increase in memory usage, unless my initial assumptions were wrong.

I'll try running the test to see if it uses WebGL. That would explain the increase due to our polygon outlines being larger than what most applications need. This would be fixed by https://swiftshader-review.googlesource.com/9952, but it needs a bit more revision.
Hi Nicolas, could you provide an update to this bug? Please close it if you believe it's no longer an issue. Thanks!

Comment 9 by capn@chromium.org, Oct 4 2017

I haven't had the time yet to look into this any further. Feel free to re-assign this to the media team to investigate why this test appears to be using WebGL.
Cc: dalecur...@chromium.org
Owner: capn@chromium.org
Hi Dale, could you help answer the question from Comment #9, why the media benchmark test appears to be using WebGL? Thanks.
Status: WontFix (was: Assigned)
Stale.

Sign in to add a comment