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

Issue 750182 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 16 days ago
Closed: Sep 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

10.1% regression in blink_perf.canvas at 487894:488059

Project Member Reported by majidvp@google.com, Jul 28 2017

Issue description

May need to nudge the alert +1 but let start 
with current alert and see if bisect finds anything.


 
Project Member

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

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

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


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

chromium-rel-mac12-mini-8gb
Project Member

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

Cc: jiajia....@intel.com
Owner: jiajia....@intel.com

=== Auto-CCing suspected CL author jiajia.qin@intel.com ===

Hi jiajia.qin@intel.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 : jiajia.qin
  Commit : ca29dd7baa80c00d30039af7dcbdfc1abca6864c
  Date   : Wed Jul 19 22:34:38 2017
  Subject: Re-enable GPU-GPU copies of video textures to GL_RED

Bisect Details
  Configuration: mac_10_12_mini_8gb_perf_bisect
  Benchmark    : blink_perf.canvas
  Metric       : upload-video-to-texture/upload-video-to-texture
  Change       : 9.46% | 2102.50763702 -> 1903.53256835

Revision             Result                  N
chromium@487893      2102.51 +- 37.558       6      good
chromium@487976      2045.34 +- 86.7871      6      good
chromium@487997      2103.2 +- 145.547       6      good
chromium@488008      2123.33 +- 89.1129      6      good
chromium@488013      2083.4 +- 42.8201       6      good
chromium@488014      1988.15 +- 40.0249      6      bad       <--
chromium@488015      1972.55 +- 133.707      6      bad
chromium@488016      1944.16 +- 56.4705      6      bad
chromium@488018      1911.46 +- 136.531      6      bad
chromium@488059      1903.53 +- 92.6126      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 blink_perf.canvas

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

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


For feedback, file a bug with component Speed>Bisection
Hi majidvp, does this bug only happen on Mac? I can't reproduce it locally. The result is unstable in a range.
It seems that command 'src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.canvas' will test all the cases under canvas. Do you know how to only run 'upload-video-to-texture'? 

Looked at the CL identified. The change is to use CopySubTextureCHROMIUM to replace CopyTextureCHROMIUM. The only differ is that CopyTextureCHROMIUM can go to image->CopyTexImage path. But image->CopySubTexImage may be not supported in some platforms. So it may effect upload-video-to-texture result if it went to this path in CopyTextureCHROMIUM.
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 9 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be8f68faf9872f0da290a58ac310964b823cc3bd

commit be8f68faf9872f0da290a58ac310964b823cc3bd
Author: Jiajia Qin <jiajia.qin@intel.com>
Date: Wed Aug 09 07:14:35 2017

Fixed the incorrect copy in DoCopyTextureCHROMIUM

In GLES2DecoderImpl::DoCopyTextureCHROMIUM, it will try to use
GLImage::CopyTexImage when possible. However, GLImage::CopyTexImage
always copy same format image data to target texture and don't do
format translation. So we need to check whether the dest target's
internal format is same with source target's internal format when
we use GLImage::CopyTexImage. This is also the root cause of  BUG 710673 .

This CL also switch back CopyTextureCHROMIUM since CopySubTextureCHROMIUM
may bring performance regression. See  bug 750182 . One possible
reason is that CopyTextureCHROMIUM can use CopyTexImage on Mac. However,
CopySubTexImage hasn't been implemented on Mac. 

BUG= 710673 ,  750182 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ia171f0b3db70ee02925a4ee15447f9c0ceda1dae
Reviewed-on: https://chromium-review.googlesource.com/582160
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Jiajia Qin <jiajia.qin@intel.com>
Cr-Commit-Position: refs/heads/master@{#492879}
[modify] https://crrev.com/be8f68faf9872f0da290a58ac310964b823cc3bd/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/be8f68faf9872f0da290a58ac310964b823cc3bd/media/renderers/skcanvas_video_renderer.cc
[modify] https://crrev.com/be8f68faf9872f0da290a58ac310964b823cc3bd/media/renderers/skcanvas_video_renderer.h

Status: Fixed (was: Untriaged)
The performance went back up with the CL in #5

Sign in to add a comment