Seems like this issue is specific to Chrome OS, so it won't be an M53 Stable blocker for Desktop. 

Finished bisecting.

The breaking CL is:

commit 0885aff9905de9b96b197c353d4f438c173b5834
Author: robert.bradford <robert.bradford@intel.com>
Date:   Wed Jun 29 12:57:31 2016 -0700

    gpu: Use workarounds to selectively enable CMAA

Artifacts visible on the attachment.

Deleted: Screenshot 2016-08-31 at 1.47.08 PM.png 4.8 MB

	Screenshot 2016-08-31 at 1.47.08 PM.png 4.8 MB View Download

Reverting 0885aff9905de9b96b197c353d4f438c173b5834 locally fixed the issue.

@robert.bradford, @piman: Can we revert this on M53? It's going stable soon and it breaks Samus.

For M53 i'm preparing a the minimalist patch to disable (a straight revert will be messy due to the JSON file). For M54 & ToT DS is investigating if we can fix today. Otherwise we'll revert there too.

CL for M53: https://codereview.chromium.org/2296173002/

I know ordinarily that a change needs to prove itself on Canary, etc, but it's not possible for this exact CL due to the JSON file format. Is it possible to merge this to M53?

[Automated comment] Less than a week to go before stable on M53, we might already have a stable candidate build. Manual review required.

I could reproduce it on Ubuntu. I found the root cause, which doesn't restore draw buffers state after CMAA. I'll fix it soon.

Approving merge to M53 cros.

I submit the CL fixing it. https://codereview.chromium.org/2298613010
Please take a review.

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

commit 3ec0a76c3c48338c08bf489c442f69c2c03d18fd
Author: robert.bradford <robert.bradford@intel.com>
Date: Fri Sep 02 15:41:03 2016

[M53] Disable CMAA for samus

Selective enabling for CMAA on samus was added in https://crrev.com/402913 by
using a workaround with an exception to turn it on.

It was found that this caused a graphics corruption issue with the Camera app.
This CL is the minimal change to disable the feature by removing the samus PCI
ID from the list of exceptions to the workaround which disables CMAA.

BUG=642290
TEST=Bisecter reported reverting this commit resolved corruption issues.
NOPRESUBMIT=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2296173002
Cr-Commit-Position: refs/branch-heads/2785@{#812}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/3ec0a76c3c48338c08bf489c442f69c2c03d18fd/gpu/config/gpu_driver_bug_list_json.cc

@#18: that CL seems fine, but I don't think we want to take it for M53 at this point - CMAA is now disabled there.

However I assume the same issue is present on M54, and we will need to either disable it there too, or fix it with your patch. So maybe let's land it on trunk, verify that it does indeed fix it, and then consider for merge on M54.

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

commit b2d7e66345c253f353d1d3c555964f6e95e26b9c
Author: dongseong.hwang <dongseong.hwang@intel.com>
Date: Mon Sep 05 12:50:39 2016

gpu, cmaa: copy RGBA8 texture via glCopyTexSubImage2D() instead of imageStore().

CMAA uses imageStore() to copy RGBA8 to RGBA8 texture. At the moment, we
expect the FBO is not updated. However, some drivers (e.g. Intel Mesa) fill
random color on the FBO in the case. It causes ugly artifact in the later CMAA
phase.
This CL copies RGBA8 texture via glCopyTexSubImage2D(), instead of custom shader and
glDrawArrays. It fixes the bug as well as speeds up copy.

BUG=642290
TEST=chromeos camera app on Samus
https://chrome.google.com/webstore/detail/camera/hfhhnacclhffhdffklopdkcgdhifgngh
CQ_INCLUDE_TRYBOTS=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

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

[modify] https://crrev.com/b2d7e66345c253f353d1d3c555964f6e95e26b9c/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/b2d7e66345c253f353d1d3c555964f6e95e26b9c/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h

artifacts is fixed and imo initialization performance is fine.
Adrian and I are looking at performace more.
mtomasz@, could you verify if it's fixed?

We'd like to merge the fix in #21 to the R54 branch.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit 41f75bc0f1ac9e8956007c1c7d95180e7efaf225
Author: Rob Bradford <robert.bradford@intel.com>
Date: Mon Sep 12 16:14:18 2016

gpu, cmaa: copy RGBA8 texture via glCopyTexSubImage2D() instead of imageStore().

CMAA uses imageStore() to copy RGBA8 to RGBA8 texture. At the moment, we
expect the FBO is not updated. However, some drivers (e.g. Intel Mesa) fill
random color on the FBO in the case. It causes ugly artifact in the later CMAA
phase.
This CL copies RGBA8 texture via glCopyTexSubImage2D(), instead of custom shader and
glDrawArrays. It fixes the bug as well as speeds up copy.

BUG=642290
TEST=chromeos camera app on Samus
https://chrome.google.com/webstore/detail/camera/hfhhnacclhffhdffklopdkcgdhifgngh
CQ_INCLUDE_TRYBOTS=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

Review-Url: https://codereview.chromium.org/2298613010
Cr-Commit-Position: refs/heads/master@{#416538}
(cherry picked from commit b2d7e66345c253f353d1d3c555964f6e95e26b9c)

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

Cr-Commit-Position: refs/branch-heads/2840@{#299}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/41f75bc0f1ac9e8956007c1c7d95180e7efaf225/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/41f75bc0f1ac9e8956007c1c7d95180e7efaf225/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h

Verified on 53.0.2785.103 / 8530.81.0 / beta-channel samus. The problem (artifacts and slowness) are gone. Thank for quickly fixing the issue!

Can we change the status to verified?

Verified on M54 build 8743.25.0
Camera app is working fine on Samus.

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

commit 41f75bc0f1ac9e8956007c1c7d95180e7efaf225
Author: Rob Bradford <robert.bradford@intel.com>
Date: Mon Sep 12 16:14:18 2016

gpu, cmaa: copy RGBA8 texture via glCopyTexSubImage2D() instead of imageStore().

CMAA uses imageStore() to copy RGBA8 to RGBA8 texture. At the moment, we
expect the FBO is not updated. However, some drivers (e.g. Intel Mesa) fill
random color on the FBO in the case. It causes ugly artifact in the later CMAA
phase.
This CL copies RGBA8 texture via glCopyTexSubImage2D(), instead of custom shader and
glDrawArrays. It fixes the bug as well as speeds up copy.

BUG=642290
TEST=chromeos camera app on Samus
https://chrome.google.com/webstore/detail/camera/hfhhnacclhffhdffklopdkcgdhifgngh
CQ_INCLUDE_TRYBOTS=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

Review-Url: https://codereview.chromium.org/2298613010
Cr-Commit-Position: refs/heads/master@{#416538}
(cherry picked from commit b2d7e66345c253f353d1d3c555964f6e95e26b9c)

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

Cr-Commit-Position: refs/branch-heads/2840@{#299}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/41f75bc0f1ac9e8956007c1c7d95180e7efaf225/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/41f75bc0f1ac9e8956007c1c7d95180e7efaf225/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h

the CL which fixed this bug is reverted, because perf issue. so reopen this issue.
I'm fixing it in https://codereview.chromium.org/2465963002/

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

commit 6cd0a67f8256ecb9e0fb899528bdffc74f0e7042
Author: dongseong.hwang <dongseong.hwang@intel.com>
Date: Mon Oct 31 21:37:47 2016

Reland "gpu, cmaa: reduce one-copy", "gpu, cmaa: copy RGBA8 texture via glCopyTexSubImage2D() instead of imageStore()."

Original CL:
https://codereview.chromium.org/2298613010 : use glCopyTexSubImage2D, and fix Pri1 bug
https://codereview.chromium.org/2405893002 : optimize further

Revert CL:
https://codereview.chromium.org/2456913002 : glCopyTexSubImage2D regresses performance and optimization CL is reverted due to conflict.

Changes:
- fix Pri1 bug as-is
- optimize further as-is
- don't introduce glCopyTexSubImage2D, and use the existing copy shader.

BUG= 535198 , 642290,  659438 
CQ_INCLUDE_TRYBOTS=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

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

[modify] https://crrev.com/6cd0a67f8256ecb9e0fb899528bdffc74f0e7042/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/6cd0a67f8256ecb9e0fb899528bdffc74f0e7042/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h

While the artifacts are gone, the Camera app opening lag appeared again. samus 55.0.2882.0

Friendly ping, this is still broken.

56.0.2919.0 dev-channel samus test / 8990.0.0

Is this also broken in M-55?

Yes. Broken on 55.0.2883.50 / 8872.51.0.

Is this still a blocker because of the lag?

We are nearing 55 stable and this is marked as a blocker, if we can get a fix in the next two days we can make the targeted RC, if not we may have to punt or delay. 

Removing stable blocking label as this issue appears to pre date 55.

I'd really like this to be prioritized. One of the CLs in this issue was supposed to be an optimization, but caused significant performance regression on Samus. As a result Camera app initialization is slower and janky. This may affect performance not only of Camera app but all web apps using WebGL.

if that's the case, can we revert the patch in question?

Maybe, but I'm no longer sure what can we revert. IIUC, we'd need to revert #32, but according to #31, CL in #32 is needed due to another performance issue. It would be great to get some feedback from dongseong.hwang@ or robert.bradford@.

#c40 - sorry for delaying response. I came back from vacation.
How can I know whether it's lag or not. Could you share your test method or criteria?

If we decide we have to revert, we can disable CMAA on Samus.
However, I saw significant performance boost-up on Pixel 2 as figure shows
The test sites are
http://webglsamples.org/aquarium/aquarium.html
http://arodic.github.io/p/jellyfish/
http://webglsamples.org/google-io/2011/40000-objects-optimized.html

Deleted: cmaa.png 16.0 KB

	cmaa.png 16.0 KB View Download

Hm, it's not good to lose such performance boost either.

@dongseong.hwang: Can your patches make either WebGL context creation or shader initialization creation slower?

Testing criteria: Launch Camera app. The window animation and the loading spinner should be smooth, without jank.

@dongseong.hwang: The jank is quite prominent, it's like around 1 second. chrome://tracing should show what's the reason. Let me know if you need any help debugging it.

@dongseong.hwang, any update?

I took a look at it, as it kept bothering me. The cause of the sluggishness is very slow Initialization of CopyTextureCHROMIUMResourceManager, which in Pixel 2 takes 3x250ms which is around 750 of frozen thread in one go. This is waaaay to sloow.

mtomasz@, thank you for commenting. I could not respond because I moved from Europe to US recently.
It must be because CMAA did lots of tests about FBO when initialization. I'll make it happen only once or replace this with extension check. Sorry for delaying.

Should this still be P1?

@dongseong.hwang: Do you have cycles to work on it? If not, then shall we revert?
@ajuma: I believe so. It's a regression.

Doesn't reproduce on samus 56.0.2924.89 dev-channel

Sorry for delaying response. It's good news. Probably latest mesa has some speed improvement. e.g. fbo binding, program compiling or creating/deleting texture.

BTW, the root cause was that CMAA run lots of unnecessary checks in initialization time. I'm removing the tests in https://codereview.chromium.org/2693653002/

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

commit 8d2609f6aa6f0a9f8ae238b8af06770337d726eb
Author: dongseong.hwang <dongseong.hwang@intel.com>
Date: Tue Mar 07 19:11:09 2017

cmaa, gpu: use R8 image texture when GL_NV_image_formats is available.

Recently Mesa supports GL_NV_image_formats extension for r8 image texture for ES 3.1.
https://bugs.freedesktop.org/show_bug.cgi?id=98480
So CMAA can use R8 texture, instead of RGBA8.

In addition, CMAA implementation checks R8 support tests, and it slows down GPU
initialization. Remove all unnecessary tests and just check certain extensions.

BUG= 535198 , 642290
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

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

[modify] https://crrev.com/8d2609f6aa6f0a9f8ae238b8af06770337d726eb/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/8d2609f6aa6f0a9f8ae238b8af06770337d726eb/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/8d2609f6aa6f0a9f8ae238b8af06770337d726eb/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h
[modify] https://crrev.com/8d2609f6aa6f0a9f8ae238b8af06770337d726eb/gpu/command_buffer/service/gles2_cmd_decoder.cc

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

commit 870bce2d5e6ed3ba5d7b513b69d55fdb26efc2d6
Author: zmo <zmo@chromium.org>
Date: Thu Mar 09 18:39:22 2017

Revert of cmaa, gpu: use R8 image texture when GL_NV_image_formats is available. (patchset #4 id:60001 of https://codereview.chromium.org/2693653002/ )

Reason for revert:
This breaks:
https://build.chromium.org/p/chromium.gpu/builders/Linux%20Debug%20%28NVIDIA%...

Error from the output:
[4533:4533:0307/120003.054303:1731388651:ERROR:gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc(647)]
ApplyFramebufferAttachmentCMAAINTEL: shader compilation failed:
GL_FRAGMENT_SHADER shader compilation failed: 0(1) : error C0000: syntax error,
unexpected $undefined at token "<undefined>"
0(1) : error C0155: integer constant overflow
0(4) : warning C7022: unrecognized profile specifier "highp"
0(4) : warning C7022: unrecognized profile specifier "precision"

Original issue's description:
> cmaa, gpu: use R8 image texture when GL_NV_image_formats is available.
>
> Recently Mesa supports GL_NV_image_formats extension for r8 image texture for ES 3.1.
> https://bugs.freedesktop.org/show_bug.cgi?id=98480
> So CMAA can use R8 texture, instead of RGBA8.
>
> In addition, CMAA implementation checks R8 support tests, and it slows down GPU
> initialization. Remove all unnecessary tests and just check certain extensions.
>
> BUG= 535198 , 642290
> 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
>
> Review-Url: https://codereview.chromium.org/2693653002
> Cr-Commit-Position: refs/heads/master@{#455170}
> Committed: https://chromium.googlesource.com/chromium/src/+/8d2609f6aa6f0a9f8ae238b8af06770337d726eb

TBR=dongseong.hwang@chromium.org,piman@chromium.org,kbr@chromium.org,machenbach@chromium.org,dongseong.hwang@intel.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 535198 , 642290

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

[modify] https://crrev.com/870bce2d5e6ed3ba5d7b513b69d55fdb26efc2d6/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/870bce2d5e6ed3ba5d7b513b69d55fdb26efc2d6/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/870bce2d5e6ed3ba5d7b513b69d55fdb26efc2d6/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h
[modify] https://crrev.com/870bce2d5e6ed3ba5d7b513b69d55fdb26efc2d6/gpu/command_buffer/service/gles2_cmd_decoder.cc

To calarify my earlier #56 comment, I checked recently and this is actually still broken on samus ToT.

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

commit 96e2b1d93e12bca0b76edb58a83ec9898dc80962
Author: dongseong.hwang <dongseong.hwang@intel.com>
Date: Thu Mar 16 00:19:12 2017

Reland cmaa, gpu: use R8 image texture when GL_NV_image_formats is available.

Original CLs:
https://codereview.chromium.org/2693653002/

Notable Changes:
- Fix the bug about std::ostringstream.

BUG= 535198 , 642290
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

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

[modify] https://crrev.com/96e2b1d93e12bca0b76edb58a83ec9898dc80962/gpu/command_buffer/service/feature_info.cc
[modify] https://crrev.com/96e2b1d93e12bca0b76edb58a83ec9898dc80962/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.cc
[modify] https://crrev.com/96e2b1d93e12bca0b76edb58a83ec9898dc80962/gpu/command_buffer/service/gles2_cmd_apply_framebuffer_attachment_cmaa_intel.h
[modify] https://crrev.com/96e2b1d93e12bca0b76edb58a83ec9898dc80962/gpu/command_buffer/service/gles2_cmd_decoder.cc

Verified in Chrome OS 9565.0.0;60.0.3102.0. 

Sorry, this still seems to be broken. Camera app initialization on Caroline is very slow and janky.

On 60.0.3108.0 / 9601.0.0 caroline test

donseong, could you please update on any plans to fix this P1 issue?

This bug has been reopened a lot of times, should we change how we approach the problem?