I kicked off a bisect: https://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/679

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

Hi erikchen@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 : Pass responsibility for IOSurface-texture reuse to the gpu process.
Author  : erikchen
Commit description:
  
The GLRenderer uses the new command buffer function
glScheduleCALayerInUseQueryCHROMIUM to determine whether textures are still in
use by the system compositor. This means that GpuMemoryBufferIds no longer need
to be plumbed through to the browser process.

BUG= 608026 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2061993003
Cr-Commit-Position: refs/heads/master@{#400732}
Commit  : 1ed6908a7a46dde512db953c77e343a63f41630f
Date    : Mon Jun 20 18:29:12 2016


===== TESTED REVISIONS =====
Revision         Exit Code  Std Dev  N  Good?
chromium@400718  0          N/A      3  good
chromium@400726  0          N/A      3  good
chromium@400730  0          N/A      3  good
chromium@400731  0          N/A      3  good
chromium@400732  1          N/A      3  bad    <--
chromium@400733  1          N/A      3  bad
chromium@400747  1          N/A      3  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 621899

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests media.tough_video_cases
Test Metric: idle_wakeups_total/video.html?src_tulip2.mp4
Relative Change: Zero to non-zero
Score: 99.9

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


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

| 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!

Some combination of the telemetry/the test page appears to be broken.

I ran the benchmarks locally, and everything worked fine. But I noticed that some of the pages didn't have any video playing. I modified ToughVideoCasesPageSet to only include the 4 pages mentioned in c#0. This time, I saw a hang. As before, no video was played. So then I tried opening the video in Chrome Canary - works fine, no problem. Then I tired opening the video in Chromium - nothing plays!

I tried a bisect all the way back to r350000, and the video never played. The error is 
"[48573:1295:0621/135725:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR demuxer: could not open
"

It looks like this page has been broken for a while, but for some reason, Telemetry wasn't correctly catching the fact that it doesn't work with Chromium. Assigning back to sandersd for further investigation.

One more thing: I manually built Chromium with my CL reverted, and it still can't play the video file:///Users/erikchen/projects/chromium3/src/tools/perf/page_sets/tough_video_cases/video.html?src=crowd1080.mp4

The reason that nothing played was probably because this is H264 video. H264 video does not play in Chromium: it only plays in Chrome. Note the "--browser=release" flag in the test command above.

--browser=release does not force a Chrome build. Are we sure that the Telemetry tests use an official build rather than a Chromium build?

I'm not sure that the build is official, but I do know that the default way to build Chromium does not allow playing H264 video. So Telemetry must be doing something special here.

Erik,

In order to play H264 video, you need to enable proprietary codecs and set branding to "Chrome". Dan Sanders should be able to help you build Chrome that plays H264 if you have further questions.

I've been able to reproduce the problem on a MBP, but not my MacPro. The browser's cc::ResourceProvider is never returning any frames, because they are always "in use". Need to investigate further, and determine the best course of action. We can't trivially revert, because ccameron@ has already started ripping out some logic that this was supposed to replace.

As a short term solution, I'll probably disallow holding onto any given texture for more than a couple of frames.

For h264, the CVPixelBufferPool does the necessary in-use checking, so we can return these to the renderer immediately.

Probably the way to go here is to add a flag to GLImageIOSurface::InitializeWithCVPixelBuffer to say "this thing isn't in use, don't say that it is", and have h264 (the only caller) specify that.

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

commit 0f5be6cf7b919397dd97ee350b1a663227ac13ea
Author: erikchen <erikchen@chromium.org>
Date: Wed Jun 22 06:45:10 2016

Don't check IOSurfaceIsInUse for IOSurfaces wrapped in a CVPixelBuffer.

It always returns true, even when the Window Server is no longer using it.
CVPixelBufferPool does the appropriate checking.

BUG= 621899 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2085173002
Cr-Commit-Position: refs/heads/master@{#401217}

[modify] https://crrev.com/0f5be6cf7b919397dd97ee350b1a663227ac13ea/gpu/ipc/service/image_transport_surface_overlay_mac.h
[modify] https://crrev.com/0f5be6cf7b919397dd97ee350b1a663227ac13ea/gpu/ipc/service/image_transport_surface_overlay_mac.mm
[modify] https://crrev.com/0f5be6cf7b919397dd97ee350b1a663227ac13ea/ui/gl/gl_image_io_surface.h
[modify] https://crrev.com/0f5be6cf7b919397dd97ee350b1a663227ac13ea/ui/gl/gl_image_io_surface.mm

[Automated comment] Commit may have occurred before M53 branch point (6/30/2016), needs manual review.

M53 is NOT branched yet (it is branching on June 30th). No approval is needed.

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

commit 9c0c4f89a3fceb36a8b9d9b4d4d39618f4fb09fb
Author: Erik Chen <erikchen@chromium.org>
Date: Tue Jun 28 20:30:14 2016

[Merge to 2774] Don't check IOSurfaceIsInUse for IOSurfaces wrapped in a CVPixelBuffer.

It always returns true, even when the Window Server is no longer using it.
CVPixelBufferPool does the appropriate checking.

BUG= 621899 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2085173002
Cr-Commit-Position: refs/heads/master@{#401217}
(cherry picked from commit 0f5be6cf7b919397dd97ee350b1a663227ac13ea)

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

Cr-Commit-Position: refs/branch-heads/2774@{#11}
Cr-Branched-From: b0f304cf34c7a20dcab2f8de8f4941521c6a0f9b-refs/heads/master@{#400850}

[modify] https://crrev.com/9c0c4f89a3fceb36a8b9d9b4d4d39618f4fb09fb/gpu/ipc/service/image_transport_surface_overlay_mac.h
[modify] https://crrev.com/9c0c4f89a3fceb36a8b9d9b4d4d39618f4fb09fb/gpu/ipc/service/image_transport_surface_overlay_mac.mm
[modify] https://crrev.com/9c0c4f89a3fceb36a8b9d9b4d4d39618f4fb09fb/ui/gl/gl_image_io_surface.h
[modify] https://crrev.com/9c0c4f89a3fceb36a8b9d9b4d4d39618f4fb09fb/ui/gl/gl_image_io_surface.mm