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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OD7rAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IqlgggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KnsuAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IDB4QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NG06QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Nq14woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NPfiwgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M3jsgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtJ-8lQgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JjC9gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKqyhggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9I6w5woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MSX6AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9K2ougoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KnsuAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNfh4gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtOWv1ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjMCXoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MaQrgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LLvlggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtJ-8lQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IuHpwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ODC6AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M354wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Nq14wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtOf_7woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9InIjQgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtJe56AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PGA7woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OnHrwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjIDrsgsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IDBkQgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OKXowsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KWDxwgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Mep9AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KyDlwgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JXpwgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MDdkwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPOq-wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KyDlwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KTLogkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LyixAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M23qwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PHuyQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Ki9hAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNXFggkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PHuyQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ImG_QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Nq14wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PWq8wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JeTqgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JWnsgsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNW0lQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Pqs6AsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtLfpvwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IDB4QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPew6QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Iql_AsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Mep9AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M3jsgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9J6TugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IS_pwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Ib4ogsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MLj6ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PGA7wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MbqoQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9I3moQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PW-6goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LqO9goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NPfiwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtImflAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PyP7wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OKXowkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LyixAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjIDr8ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNfhogsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MjVlggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MDdkwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjIC_qwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IDB4QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NGqhAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9O6W6QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PqwsQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JXpggkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPew6QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Kns-AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ODC6AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LOn_wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNW0lQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Lj82gsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtN_k2wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NGqhAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNec7AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjMDS5wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ITrugsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LOn_woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNecrAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IS_pwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtMrrkwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PHuiQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KKRvwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OW1yAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKqy-gsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNfh4goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KCv4AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JLsqwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JnQvgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OftuQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPew6QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OW1iAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPu47wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M35owsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKPO-wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OW1iAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPPFtwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNfh4gsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9J6TugkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Iql_AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IKC4AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNfh4ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Jj7iQgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjIDr8goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Lrn4AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KCvoAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKqyhgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9K2ougkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtN_kmwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PHuiQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ImG_QoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKegiAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PH56AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PaO4wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKPO-wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M2K7QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNPvmAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OXfhAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JWn8ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JLsqwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9InIjQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LLv5gsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Ki9hAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KrU8QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtLOH4gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PaO4woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KShrAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9IS_5wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NPf8wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjMCZrwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Nr67QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Lj82gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LackQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjMCZrwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9J73pwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KWDhwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtN_k2woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKfKhAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Oft-QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Kfq6wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjMCDvgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Ki9-AsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NG06QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9OW1iAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9I3moQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LWH7AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PGA7wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JjC9goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtPPF9woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JO54AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JWn8goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MfihAgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9MaQrgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNOanwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtM7m7wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjKDwsQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NGTrQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9InI9QsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtNOa3wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KrUsQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KKbsAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtMnirAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9PyP7woM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9NPfiwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KKb8AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LimxwgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9ICsngsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9Lj82goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjIC_6wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9JO54AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtM7m7wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9KCvoAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9M3U9AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg9LLvlgoM


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

chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-x64-dual
chromium-rel-win8-dual

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

time-to-play metric also regressed in this range. tracked in  issue 702332 

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

Hi sugoi@chromium.org, 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 : sugoi
  Commit : 842efc6922b0cd66febd6f36f04318ebf396c184
  Date   : Tue Mar 14 18:10:39 2017
  Subject: Moving SwiftShader from component to bundled library

Bisect Details
  Configuration: win_8_perf_bisect
  Benchmark    : media.tough_video_cases
  Metric       : processes_delta/crowd.ogg

Revision             Result          N
chromium@456705      0.0 +- 0.0      6      good
chromium@456738      0.0 +- 0.0      6      good
chromium@456754      0.0 +- 0.0      6      good
chromium@456762      0.0 +- 0.0      6      good
chromium@456763      0.0 +- 0.0      6      good
chromium@456764      1.0 +- 0.0      6      bad       <--
chromium@456766      1.0 +- 0.0      6      bad
chromium@456770      1.0 +- 0.0      6      bad
chromium@456834      1.0 +- 0.0      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 media.tough_video_cases

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8984947852434499664

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6131462270615552


| 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 Speed>Bisection.  Thank you!

Explanation:

This test is measuring something called process_delta. The way this works is that after Chrome is started, but before the test actually starts playing the audio, the test harness takes a snapshot of the number of processes that are running. After the test is over and Chrome has stopped playing audio, the test takes another snapshot. The delta is the number of processes running after minus the number of processes running before. The idea is that we want to make sure we don't accidentally leave processes running that are no longer needed.

This is at least my guess about how this works. Maybe johnchen@ or chcunningham@ knows more about the code?

The explanation by crouleau@ covers the essentials of how process_delta is measured. The test harness walks the process tree to count all the child processes of the main Chrome process, both before and after the audio is played. Any change in the number of child processes is reported as process_delta.

Ah, ok, I understand now. So, generally, when we have a valid GPU, Chrome fires up the GPU process right away in order to use accelerated features and it's alive both at the beginning and at the end of the test (so no delta).
Before the SwiftShader change, the GPU process was never getting fired up on the bots.
Now, what seems to happen is that Chrome starts, but does not start the GPU process since there's no GPU (it's a VM). Something in the test triggers the GPU process to start (using SwiftShader). At the end, the GPU process is still alive and the process delta is 1.

So, AFAIK, it can be either:
1) There's a bug and the GPU process is started for no reason (not likely, but possible)
2) The test could do something to try to start the GPU process before counting the number of processes initially
3) The test could ignore the GPU process in its process count, if that's possible.

I'll investigate point 1.

Thanks for taking a look!

One thing to keep in mind is that this CL has been marked as causing a regression for multiple metrics:
 - vm_working_set,  Issue 702337 
 - time_to_play, 702332

These other metrics were tracked in separate bugs but the bisect tool automatically marked those as duplicates of this issue and monorail UI doesn't do a great job of surfacing that. 

I suspect its also regressed vm_shared_dirty_delta,  Issue 702002  (though bisects have not found a culprit yet).

It is very unlikely that it caused  Issue 702002  since the CL was a Windows only change and that issue applies to Android bots.

Ack, ignore  Issue 702002 . 

I still haven't figured out exactly where the issue comes from. It should be fairly straightforward to find. Essentially, SwiftShader gets enabled in GpuDataManagerImplPrivate::EnableSwiftShaderIfNecessary(), which in turn causes GpuDataManagerImplPrivate::GpuAccessAllowed() to return true. This then allows the creation of a GPU process. All of that is normal.
But video decoding shouldn't be trying to use the GPU at this point, because all GPU features, including GPU_FEATURE_TYPE_ACCELERATED_VIDEO_DECODE are blacklisted. I understand the processes_delta issue, but I don't get why there are performance regressions yet.

I think these regressions are just the new expected behavior. For example:

- The 'processes_delta' change:
  Before the cl which caused this regression, we were in one of 2 cases:
  - A valid GPU is present by default
  - No valid GPU detected and the GPU process will not get created even if a GPU channel is requested
  After the cl, the behavior is:
  - No GPU process is present by default, but requesting a GPU channel creates one with SwiftShader

- The 'time_to_play' regression:
  For the same reason as the previous regression, a GPU process is created the first time a video plays (this is a one time cost) if no GPU process exist yet. At that point, one is created and this is not done at 0 cost. It's just that the cost used to have already been paid at this point.

Explanation:
When pressing "play" on a video, RenderFrameImpl explicitly requests a GPU channel (which ends up creating the GPU process) by calling RenderThreadImpl::SharedMainThreadContextProvider() here:
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?l=2835

This can be fixed by GetSharedMainThreadContext3D() receive the "provider" argument by a RenderThreadImpl* and calling SharedMainThreadContextProvider() within GetSharedMainThreadContext3D() rather than at the line mentioned above.

Unfortunately, this would not be enough. A few calls later, the creation of gpu_factories in RenderThreadImpl::GetGpuFactories() also establishes a GPU channel here:
https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?l=1383

This happens through the creation of the media player following these steps:
https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?l=2937
https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?l=191
https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?l=1727
https://cs.chromium.org/chromium/src/media/renderers/default_renderer_factory.cc?l=111

So unless someone who knows more than me about this code refactors these classes in order to use the GPU channel as more of an on-demand service, rather than something that's always created when media starts playing, these regressions are going to stay.

Note that these are not new behaviors. These are behaviors that existed before, but were untested by the bots. Reverting the cl that caused the regressions would simply re-hide these problems, so I don't think that should be considered as a possibility.

+Dale FYI. This is the cause of https://chromeperf.appspot.com/report?sid=b4460f36ca346674a4cdde4eaf2ad34dd6eea8d33ed3d2c7a232e182f0497880&start_rev=452825&end_rev=465537 Is there any further action needed?

That's a pretty huge regression in time to playback. It seems like we should defer the GPU process startup by making the suggestions in c#13. I.e. don't trigger any GPU related behavior if 1) we don't need to yet. and 2) if there are no GMBs or GVDs. These changes would be beneficial outside of tests in the normal case it seems too.

+sandersd@ want to take a look at this?

In my humble opinion ~25% is not that big of a regression. And before September 2016 the time to playback was higher for everybody. Note that this is only affecting the tests and about 10% of users; those who have a blacklisted GPU.

That said, leaving things as-is might hide further regressions or reduce future improvements (or at least give the impression of it), so I'd still recommend not launching the GPU process until you have to and know the GPU can be used.

Time to play is like search speed in terms of $$$/ms due to abandonment, so if 10% of users on YouTube/Vimeo/Facebook/etc are taking XXX more ms to start playback, that's definitely something we definitely want to address. I agree that it was higher before, so we don't need to revert this or anything like that, we just need to look into making the suggested improvements.

This has been opened for a while and I don't think there's anything we can do on the SwiftShader side, so assigning to dalecurtis@ for proper assignment of this issue to someone in the Media team or to simply close it if this won't be addressed.

Graphs won't even load any more, so it's hard to say what's happened since. The ones that do load show original levels, so seems closable.