More granular bisect, +cc sunnyps, reed as your commits may be relevant?

You are probably looking for a change made after 487969 (known good), but no later than 487997 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/b54ae33872700a909e2e20990a25f6ccad2f0174..af62f4da307a373b8c74fd986b20d48fc25f7775

This might be because of ericrk's workaround for the stencil buffer problems: https://chromium-review.googlesource.com/c/578376/

Also seeing this. Bisect gave me the same result as comment 1.

FWIW, opening devtools and switching to device mode (next to the inspect-element button) makes the page render temporarily.

(Same GPU model as OP.)

Reverting https://chromium-review.googlesource.com/c/578376/ in https://chromium-review.googlesource.com/c/584127 . Not sure whether it will apply cleanly; we'll see.

If it turns out this was the culprit then we should figure out why. It seems to imply that it wasn't taking effect on these dual-GPU machines, but it should have been.

+zmo because this is tied in to GPU information querying and application of the blacklist.

https://chromium-review.googlesource.com/584127 landed at r489252 .

Testing with a Chromium continuous build at r489460, the problem seems to be gone when visiting https://www.theverge.com/ . However, I also can't reproduce with a Chromium continuous build at r489249.

phulce@, bkenny@, do you have other scenarios that were failing that we could use to verify? Otherwise we can wait for the next Canary.

I've attached a Lighthouse report that also wasn't rendering anything yesterday, however phulce and I can no longer reproduce a problem with either page at r489161. Not sure if that's expected or not.

Deleted: www.cnn.com_2017-07-24_17-40-10.html 2.4 MB

www.cnn.com_2017-07-24_17-40-10.html 2.4 MB View Download

That's unexpected. Maybe the blacklist entry I reverted wasn't actually the problem.

Can you bisect with Chromium continuous builds on your affected hardware? Do they reproduce, or do you need official builds?

A quick bisect for the working version gives

You are probably looking for a change made after 489139 (known bad), but no later than 489148 (first known good).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/4a07e22a932cb25cc338f6c10f6d04932ef95bd9..964e8be1a2270b84dd34ac4d9503d2818e35faa1

Sorry, missed this earlier. FWIW, my blacklist change which kbr@ reverted doesn't appear to have had the impact I was hoping for (it was also speculative), so no need to worry about re-landing.

OK, sorry Eric for reverting but glad we don't have to worry about re-landing.

The failure here is still really concerning. Any chance someone with the affected hardware on corp can please do a per-revision bisect to find both when it really started failing and what fixed it? Please see:

https://sites.google.com/a/google.com/chrome-te/home/tools/bisect_builds

Thanks.

A per-revision bisect for the source of the issues still points to Eric's change

You are probably looking for a change made after 487996 (known good), but no later than 487997 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/f9d9f32962c7c1606ffb0d7f3a06cce14e470b64..af62f4da307a373b8c74fd986b20d48fc25f7775

A per-revision bisect for the fix points to +vmpstr's change

You are probably looking for a change made after 489146 (known bad), but no later than 489147 (first known good).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/cf97ed5bc86f3ec5ede7392671b7cc2e6d9a85dd..53a4abf18f931bf3014ab8e849f4f842b9e6c32a

Thanks phulce@ for following up. Interesting that vmpstr@'s change fixed this too.

It seems that the revert of the blacklist change should stay, so closing this as WontFix since there was no associated code change, only a revert.