Unable to reproduce the issue on 64.0.3282.85/10176.44.0 - link device

Reproducible on 10176.44.0/64.0.3282.85 - Snappy

Checked this issue on reported version #64.0.3282.85/0176.44.0 beta-channel Reks and on latest beta version #64.0.3282.85/10176.45.0 beta-channel Reks,Candy and Daisy .Unable to repro the issue  and attaching videos for reference

Deleted: OnBuild10176.45.0.mp4 5.4 MB

	OnBuild10176.45.0.mp4 5.4 MB View Download

Deleted: OnBuild10176.44.0.webm 5.6 MB

	OnBuild10176.44.0.webm 5.6 MB View Download

It looks like a Maps issue, maybe on a transient Maps build? It looks like missing tiles or LODs.

Sending to submitter: Does it still repro? If so, please attach about:gpu logs, and also check for crashes in about:gpu.

I'm still able to reproduce the issue on 64.0.3282.85/10176.44.0(kevin), 64.0.3282.87/10176.47.0 - reef(Electro).

Please see attached "about:gpu" files.

Deleted: gpu_info.zip 20.7 KB

gpu_info.zip 20.7 KB Download

Seen in the reef logs:
[1570:1570:0112/113927.695259:ERROR:gles2_cmd_decoder.cc(10002)] : [.Offscreen-For-WebGL-0x99649c2a000]RENDER WARNING: there is no texture bound to the unit 0
[1570:1570:0112/113927.695494:ERROR:gles2_cmd_decoder.cc(10002)] : [.Offscreen-For-WebGL-0x99649c2a000]RENDER WARNING: there is no texture bound to the unit 0

That would translate to black. It does sound like it's just Maps not streaming the textures in time and leaving them unset?

I'm not able to reproduce the issue on chrome 63.0.3239.140/10032.86.0 - reef(Electro). And, there is error messages on about:gpu logs : 
[5764:5764:0112/144236.067605:ERROR:gles2_cmd_decoder.cc(9875)] : [.Offscreen-For-WebGL-0x10f843a77400]RENDER WARNING: there is no texture bound to the unit 0
[5764:5764:0112/144236.068246:ERROR:gles2_cmd_decoder.cc(9875)] : [.Offscreen-For-WebGL-0x10f843a77400]RENDER WARNING: there is no texture bound to the unit 0

==== 
So far, I'm seeing the issue only on maps.google.com.

Deleted: m63_gpuinfo_electro_reef.zip 10.8 KB

m63_gpuinfo_electro_reef.zip 10.8 KB Download

Ok. Sounds device-specific and bisectable. ->marcheu to find a Chrome OS gfx owner

Antoine, the different comments say that the bug happens on both kevin (ARM/Mali) and reef (intel). It sounds to me like this is actually not device-specific?

Well, it doesn't seem to repro on link (#1, also tried locally) or Reks, Candy (not sure what those are) or Daisy (#6), so I don't know.
The behavior seen in the video still makes me think it's a maps issue.
kbr, zmo: any idea?

The warnings about:
[5764:5764:0112/144236.067605:ERROR:gles2_cmd_decoder.cc(9875)] : [.Offscreen-For-WebGL-0x10f843a77400]RENDER WARNING: there is no texture bound to the unit 0

seem to be unrelated.

I've tested on a MacBook Pro with NVIDIA discrete GPU and Air with Intel HD 6000 GPU and neither repro.

From the video, it looks to me like incomplete frames are being rendered. This sounds a lot like a problem we saw on macOS in  Issue 769488  where macOS' CGL window system layer didn't obey flush ordering. This problem started exhibiting itself when Chrome started making more aggressive scheduling decisions about its GPU work. I can imagine that a similar issue might exist in the EGL implementation on ChromeOS. Have we tried inserting glFlush calls in GLContextEGL::Makecurrent and ReleaseCurrent:

https://cs.chromium.org/chromium/src/ui/gl/gl_context_egl.cc?l=217
https://cs.chromium.org/chromium/src/ui/gl/gl_context_egl.cc?l=259

similarly to how they were added on macOS:

https://cs.chromium.org/chromium/src/ui/gl/gl_context_cgl.cc?l=245
https://cs.chromium.org/chromium/src/ui/gl/gl_context_cgl.cc?l=283

?

@#15: I don't think it's the same bug... On ARM/Mali we use virtualized contexts, so cross-context synchronization shouldn't be an issue (if it was we'd need more than glFlush anyway - i.e. full barriers using eglFenceSync/eglWaitSync). On X86, Mesa guarantees a glFlush (which is enough) on eglMakeCurrent.

Nothing pops out on top of my head. If it's bisectable, let's bisect, see which CL makes the regression, and understand better what's going on.

Could be shot in the dark, but I am currently fighting a similar problem on custom Android with the latest QCom GL driver. That driver changes behavior of the depth/stencil buffer in the case when FramebufferTexture2DMultisampleEXT is used: "[After flush] If texture is a depth or stencil texture, the contents of the multisample        buffer is discarded rather than resolved - equivalent to the application        calling InvalidateFramebuffer for this attachment." (see https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture2.txt)

So, what it means that after flush you lose depth/stencil buffer (in multisample case). The worst of all - you don't have to call glFlush explicitly: instead, eglMakeCurrent call causes implicit Flush. Thus, if you have WebGL rendering happening and then the Browser compositor decides to update the page rendering (DrawAndSwap()), this will cause context switching in pretty much unpredictable moment (?), will discard the depth/stancil buffer of your unfinished WebGL rendering, causing flickering and all kind of artifacts. Even if it doesn't do that, the performance hit is pretty bad. Does it sound plausible? 

#18: Thanks for your feedback; that does sound like a similar symptom, though I don't think any of the GPUs involved here are from Qualcomm.

Is your application web- and WebGL-based? If so, do you have a test case for the situation you're seeing?

+sunnyps as this may be related to recent GPU scheduling changes. Ideally we'd issue all of the WebGL context's work to the GPU consecutively -- which should already be the case, I think.

If this is easy to repro and repros consistently, I can try building locally with preemption disabled for WebGL context (or all contexts) and see if it repros.

@#18, this is a useful idea, but as kbr@ mentioned, this is almost certainly unrelated, as none of these devices use Qualcomm. Could you please file a separate bug, that includes the contents of about:gpu?

It sounds like the behavior of EXT_multisampled_render_to_texture2 (which appears to be layered on top of EXT_multisampled_render_to_texture, and enabled automatically, even though it removes some of the guarantees of EXT_multisampled_render_to_texture) is problematic, but we could disable EXT_multisampled_render_to_texture support if EXT_multisampled_render_to_texture2 is present (at least until we can fix how we interact with it).

#19: it doesn't really matter if it is QCom or not. The question is: does the GL driver follow the spec of FramebufferTexture2DMultisampleEXT ? If it does, then this is what you get, sooner or later. 
Unfortunately, this issue is reproducible only with the specific GL drivers. 
The EXT_multisampled_render_to_texture2 has the same issue with discarding depth/stencil buffer after [implicit] Flush as well. The only way to fix it, imo, is guarantee uninterruptible execution of WebGL commands. Not sure how easy that could be.

It's a chrome-side regressions; I'm bisecting chrome...

3a29249f6ceb860047ea9274a6b639d41654d1b1 is the first bad commit
commit 3a29249f6ceb860047ea9274a6b639d41654d1b1
Author: Kenneth Russell <kbr@chromium.org>
Date:   Sun Dec 31 14:38:31 2017 -0700

    Manually handle WebGL's premultipliedAlpha:false with GpuMemoryBuffers.
    
    Most OS compositors expect premultiplied alpha content. If the user
    selects non-premultiplied rendering and WebGL is rendering into a
    GpuMemoryBuffer, then make one last copy of the user's rendered
    content into the GMB, premultiplying alpha at that point. This allows
    the OS's compositor to handle premultipliedAlpha:false WebGL content
    rather than falling back to Chrome's GL compositor.
    
    BUG= 786945 
    
    Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
    Change-Id: Ib43828bf9b02fcad38d210096adfc00a61804766
    Reviewed-on: https://chromium-review.googlesource.com/846478
    Reviewed-by: Kai Ninomiya <kainino@chromium.org>
    Commit-Queue: Kenneth Russell <kbr@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#526885}

:040000 040000 dd6bba90158b78073f1533a3ea7d1cfba00d8003 9f4199db9c2a06e13ab1f6eb2383e8e583de4f2c M      third_party
marcheu@marchesin:/usr/local3/chromium/src$ 

Uh oh. I'm sorry. marcheu@, could we sit down together and test ideas for fixes on one of these devices?

issue also reproduce on coral devices

Thanks to marcheu@ for working with me on this today. https://chromium-review.googlesource.com/877505 up for review fixing it.

There is some other bug in the compositor's GL renderer code path related to premultipliedAlpha=false layers. Filed  Issue 804061  to follow on to this urgently needed fix.

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

commit 49172e454bb9b07649d0368ec6fbe3f8737a8ccd
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Jan 20 04:05:22 2018

Fix condition for setting PremultipliedAlpha flag on WebGL layer.

It wasn't matching the allocation of the premultiplied_alpha_false_texture_,
leading to rendering errors on ChromeOS.

Note: an attempt was made to test this code path on macOS but there appear to be
bugs in the non-CoreAnimation code path. Will add a test for this and debug
further in a follow-on CL.

Bug:  800993 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I9a9d648df9d21026288256dbf19797e35d8fe4f3
Reviewed-on: https://chromium-review.googlesource.com/877505
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530747}
[modify] https://crrev.com/49172e454bb9b07649d0368ec6fbe3f8737a8ccd/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

Requesting merge back to both M65 and M64. This bug unfortunately significantly impacts Google Maps' rendering on many Chromebooks and needs to be merged back. The fix is very small, simple, and well-understood, and has been verified on the affected hardware. It will merge back cleanly to both branches.

This bug requires manual review: We are only 2 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

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

commit 8442507586da4ea791b58c6a4f92866462ff59e2
Author: Kenneth Russell <kbr@chromium.org>
Date: Mon Jan 22 19:20:03 2018

Fix condition for setting PremultipliedAlpha flag on WebGL layer.

It wasn't matching the allocation of the premultiplied_alpha_false_texture_,
leading to rendering errors on ChromeOS.

Note: an attempt was made to test this code path on macOS but there appear to be
bugs in the non-CoreAnimation code path. Will add a test for this and debug
further in a follow-on CL.

TBR=kbr@chromium.org

(cherry picked from commit 49172e454bb9b07649d0368ec6fbe3f8737a8ccd)

Bug:  800993 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I9a9d648df9d21026288256dbf19797e35d8fe4f3
Reviewed-on: https://chromium-review.googlesource.com/877505
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#530747}
Reviewed-on: https://chromium-review.googlesource.com/879164
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#18}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/8442507586da4ea791b58c6a4f92866462ff59e2/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

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

commit 7a1d7e4e7072ee829fa66f3abe59a3825d6df5aa
Author: Kenneth Russell <kbr@chromium.org>
Date: Mon Jan 22 19:23:08 2018

Fix condition for setting PremultipliedAlpha flag on WebGL layer.

It wasn't matching the allocation of the premultiplied_alpha_false_texture_,
leading to rendering errors on ChromeOS.

Note: an attempt was made to test this code path on macOS but there appear to be
bugs in the non-CoreAnimation code path. Will add a test for this and debug
further in a follow-on CL.

TBR=kbr@chromium.org

(cherry picked from commit 49172e454bb9b07649d0368ec6fbe3f8737a8ccd)

Bug:  800993 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I9a9d648df9d21026288256dbf19797e35d8fe4f3
Reviewed-on: https://chromium-review.googlesource.com/877505
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#530747}
Reviewed-on: https://chromium-review.googlesource.com/879069
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#568}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/7a1d7e4e7072ee829fa66f3abe59a3825d6df5aa/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

Verify the fix on 64.0.3282.132/10176.62.0 (Kevin, Snappy),  65.0.3325.35/10323.9.0(Kevin)

Verify the fix on 64.0.3282.134/10176.65.0, 65.0.3325.35/10323.9.0(Electro_reef)

Verify the fix on 64.0.3282.134/10176.65.0, 65.0.3325.35/10323.10.0 (coral-robo360)