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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICguNyQvgkM


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

chromium-rel-mac11

This seems to be related to https://codereview.chromium.org/1867163002. Chris, could you take a look?

If I revert that change locally (well actually, just change the glFinish() to a glFlush()), the performance recovers by 10% on the Chalkboard demo. This is on a MBP 2012 NV GPU with --enable-gpu-rasterization.

glFinish() seems to be a pretty big hammer; are we certain that it's necessary here?

That change also seems to affect the Animometer "Canvas fill shapes" bench quite dramatically: reverting improves perf from 300->450. OTOH, it's possible that the lack of GPU backpressure is yielding inaccurate results. On the third hand, I didn't notice any change at all on the "Focus" bench, which is GPU-bound.

Has there been any more progress here? Did switching to glFlush() end up being the fix?

ericrk has been working on this in the context of Animometer -- He has a patch up at https://codereview.chromium.org/2028303002/

Of note is that just doing a glFlush there is insufficient -- it will increase the renderer's reported FPS, but the frames may not appear on-screen. ericrk's patch appears to avoid the problems with that mismatch, without blocking the GPU's main thread. If this benchmark is indeed GPU-bound, then his patch will not restore the performance.

Re: #7: understood. Eric describing a backpressure mechanism similar to the old rate limiter that we had (have?) in canvas, something like: block the renderer if you get more than 1-2 frames of GPU commands queued.

It looks like my change (crbug.com/2028303002) fixed the regression on mac-11 (HD 4000), mac-retina (Iris Pro), but not completely on mac-hdd (Geforce 320M). It may be that 320M doesn't handle the fence as well, or behaves differently - I think I have one of these at home, I'll do more debugging.

I'll do a bit more checking on various nVidia cards.

->ericrk to close out or duplicate.

BTW, I think that your change should be merged to M52 if it didn't make the cut.

The change indicated here (crrev.com/2028303002) addresses both this bug, as well as most of the significant (smoothness) regressions in  crbug.com/614468 . Requesting merge of crrev.com/2028303002 for M52.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still seeing odd behavior on the Mac HDD bot, but others have recovered. May investigate this later, but dropping prioritiy.

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

commit 5033c4f6e97a466f03132ed2cbb655a8807e415c
Author: ericrk <ericrk@chromium.org>
Date: Fri Jun 24 19:36:11 2016

This change blacklists GPU rasterization for all GPUs on MacOS that have not had test coverage.

The GPUs which are not blacklisted are those from the following GPU series:
Intel: 6th and 7th Generation GPUs
NVidia: Geforce 7XX GPUs
NVidia: Geforce 6XX GPUs
ATI: R300 Series GPUs
ATI: R200 Series GPUs
ATI: HD 7XXX series GPUs

This gives us roughly 70% GPU Raster enablement on Mac.

BUG= 614468 , 613272 
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/2066733003
Cr-Commit-Position: refs/heads/master@{#401933}

[modify] https://crrev.com/5033c4f6e97a466f03132ed2cbb655a8807e415c/gpu/config/software_rendering_list_json.cc

We've either addressed the regression or blacklisted the path being tested on devices where we still have a regression. Closing this out.

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

commit aded6cdaef1f360957d54578bcfffbbc7bbb00b7
Author: Eric Karl <ericrk@chromium.org>
Date: Mon Jun 27 23:47:36 2016

This change blacklists GPU rasterization for all GPUs on MacOS that have not had test coverage.

The GPUs which are not blacklisted are those from the following GPU series:
Intel: 6th and 7th Generation GPUs
NVidia: Geforce 7XX GPUs
NVidia: Geforce 6XX GPUs
ATI: R300 Series GPUs
ATI: R200 Series GPUs
ATI: HD 7XXX series GPUs

This gives us roughly 70% GPU Raster enablement on Mac.

BUG= 614468 , 613272 
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/2066733003
Cr-Commit-Position: refs/heads/master@{#401933}
(cherry picked from commit 5033c4f6e97a466f03132ed2cbb655a8807e415c)

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

Cr-Commit-Position: refs/branch-heads/2743@{#496}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/aded6cdaef1f360957d54578bcfffbbc7bbb00b7/gpu/config/software_rendering_list_json.cc

I have a 2011 Air with macOS 11.12 and its webGL only works when I override software rendering flag. It is OK on my little tests but Safari displays webGL correctly also so is it possible to remove it from the blacklist? Is is a "VENDOR = 0x8086, DEVICE= 0x0116".

#20: sorry, but the Intel HD 3000 on macOS was responsible for a disproportionately large fraction of Chrome's GPU sub-process crashes. It's for that reason that it was blacklisted and I'm sorry but we won't be revisiting that decision.Issue 592130 covers this but I see that it's restricted view; apologies for that, but it contains a lot of internal reports from Google employees.