Chromium

add  a demo

[Empty comment from Monorail migration]

[Monorail components: Blink]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Tried to reproduce this issue on chrome version #92.0.4515.107 using Windows 10 by following steps as per https://crbug.com/chromium/1233888#c0.

Steps to reproduce
================
1. Launched chrome
2. Downloaded 'test.html & test.js' and moved to single folder
3. Run the local host and open in browser
4. Clicked on test.html
5. Observed triagle with grey color
6. Navigate to Dev Tools -> Console
7. Observed empty console

Attached the screencast for reference.

@Reporter: Could you please review the attached screencast and let us know if we missed anything from our end.

Thanks..!!

Hi
Can you confirm whether you are in hardware acceler ated mode by typing chrome://gpu? Do you have two graphic cards? you can switches graphics cards (Turns on/off one or more in the control panel). By doing theses steps, we can get a webglcontextlost event.

Thank you for providing more feedback. Adding the requester to the cc list.

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

[Empty comment from Monorail migration]

[Monorail components: -Blink Blink>Canvas Blink>WebGL]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Submitter, what do you mean by "disable one graphic card on which the canvas is running"? Please tell us the exact Windows operations you performed to do this.

This is currently working as expected. Chrome doesn't know why the D3D device was lost, and assumes that the application did something to cause it. For safety reasons, WebGL is then prevented from running on the domains where it was active, until the user performs a gesture like reloading or navigating.

Hi kbr@

disable one graphic card on which the canvas is running
=======================
windows10 environment
1 open device manager
2  display adapter(I have two adapter, one is intel HD Graphics, another is NVIDIA GeForce )
3 diable one monitor that chrome webgl is running on

Hi kbr@
Why I diable graphic card is that I want to simulate the webgl context lost(I dont want use  WEBGL_lose_context）
Do you mean when we get webglcontextlost in offscreencanvas we should reload the page? We cannot restore webgl context?

The current heuristics are: if the GPU process crashes or the D3D device / OpenGL context are lost for any reason, then for any page that contained an active WebGL context, that top-level domain is blocked from creating additional WebGL contexts until the user performs an action: clicking the reload button, navigating to a page (even the same page) on that domain, etc.

These heuristics will be reevaluated in https://crbug.com/chromium/1167246, but for now, if you receive a context lost event you should prompt the user to reload the page.

Can that work for you for the present time?

Can you look in about:crashes and provide any crash IDs? We would ideally like to fix all fixable reasons why the GPU process might have crashed.

[Empty comment from Monorail migration]

1 Actually, we want to restore webglcontext successfully not by reloading the page.

2 It seems GPU Process is not crashed, as I cannot see crashed log in chrome://crashed tab.

Any updates?

@seth: In c#17 are you saying there's no crash ids when you disable the adapter? Or no crash ids when a user reports see context loss? If just when disabling the adapter, as mentioned, that isn't reflective of why a context would typically be lost, so while it's good for testing your UX it's not a path we have plans to optimize. If even in user reports you don't see any crash ids, please include the chrome://gpu logs so we can take a look.

@seth: please follow https://crbug.com/chromium/1167246 for updates to WebGL's domain blocking and context restoration heuristics.

The best approach for you right now would be to track down why the GPU process is crashing in your scenario. If you can reproduce the crashes in Chrome then please provide the crash IDs, if not also a test case. Thanks.

Adding Fidel's comments from offline discussion

> lots of customers with Teams rooms meet the problem(15 minutes zoom web client meeting on teams room will produce the problem. chronium 87)

Questions for Fidel:
- can you get a crash ID from one of these customers? (chrome://crashes)
- a lot has changed since 87. does the issue reproduce in current chrome (94)?
- can you share more details about the repro behavior? Is it important to have N participants? Do you need to enable background blur? Any extra details to recreate the crash?

- can you get a crash ID from one of these customers? (chrome://crashes)
- a lot has changed since 87. does the issue reproduce in current chrome (94)?
-----------------------
we cannot get crash id  and update the chrome version, As this device only be handled by microsoft. we have recommend them to update the version of chrome

After the work in https://crbug.com/chromium/1167246, the WebGL context is restored, but requestAnimationFrame on the worker thread stops working. Try the attached revised sample in current Chrome Canary on macOS or Windows. Open DevTools and note that draw() is called continuously; then kill the GPU process and note that webglcontextrestored is called, but draw stops being called.

Who could debug why requestAnimationFrame is broken in Web Workers after the GPU process crashes and relaunches? Justin, could you help?

I'm on it.

Thank you Justin!

What seems to be happening here is that rAF callbacks are being postponed because the canvas resource dispatcher think there are too many compositor frame in flight.  The issue is that the frames that were in flight when the GPU context crashed are never returned by the compositor.  So the offscreen canvas waits indefinitely for frame acks that will never come.

I think it is just a matter of resetting some state when the context is lost. However, I think that not all types of context losses require this.

In the WebGL context, "real" context lost notifications are hooked in at the WebGraphicsContext3DProvider level here:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc;l=1245

Is that a reliable enough indicator that earlier frame acknowledgments should be cleared out? If so can it be plumbed to the OffscreenCanvas?

The problem was a bit more complex than what I initially thought. The compositor frame sink mojo channel was not fully recovering from the gpu context loss.  This was causing the CompositorFrameAck signals to be dropped, resulting in what looked like backpressure from the compositor, thus causing the rendering loop to stall.
 
Fix is in the pipe: https://chromium-review.googlesource.com/c/chromium/src/+/3891136

Fantastic work Justin! Thank you for getting to the bottom of this!

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

commit 2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6
Author: Justin Novosad <junov@chromium.org>
Date: Tue Sep 13 13:42:27 2022

Fix rAF in Worker after gpu crash

This change ensures requestAnimationFrame keeps running in workers
after recovering from a GPU process crash.

The problem was that the compositor frame sink was getting
disconnected, which caused CanvasResourceDispatcher to block
animations because compositor respources were not being return by
the compositor. The solution was to tear down and reconstruct the
CanvasResourceDispatcher to ensure we have functioning mojo channel
to and from the compositor.

There was an existing test that was meant to verify that rAF keeps
running in workers after recovering from a GPU crash.  The test was
failing to detect this bug because it was not rendering anything in
its animation loop. Therefore it was not getting any backpressure
from the compositor. The test was re-written to be able to detect
this bug. It now has a more robust design that does a more complete
validation of the context loss lifecycle.

Bug: 1233888
Change-Id: Ic6553b486e29e20ad7154dbb9b7a8827094fcd05
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3891136
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Commit-Queue: Justin Novosad <junov@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1046332}

[add] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/content/test/data/gpu/worker-webgl-raf-after-gpu-crash.html
[delete] https://crrev.com/439c539c1b011605ad54f8d0ec5fc6cf65498465/content/test/data/gpu/worker-raf-after-gpu-crash.html
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/third_party/blink/renderer/core/offscreencanvas/offscreen_canvas.cc
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/third_party/blink/renderer/platform/graphics/surface_layer_bridge.cc
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/third_party/blink/renderer/core/html/canvas/html_canvas_element.cc
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/content/test/gpu/gpu_tests/test_expectations/context_lost_expectations.txt
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/content/test/gpu/gpu_tests/context_lost_integration_test.py
[modify] https://crrev.com/2dfa33d5be86c10f8f31e3b588061cd89a1e8cf6/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc

[Empty comment from Monorail migration]

As per https://crbug.com/chromium/1233888#c0, c#1, c#5, c#6, c#13 and c#14 issue seems to require two graphic cards setup machine to verify the fix which is currently unavailable at TE end.

seth.wang/junov@: Could you please help us in verifying the fix on latest M107(#107.0.5300.0)
Thanks..!!

[Empty comment from Monorail migration]

puramk@

I just verify on Cananry  107.0.5301.0. It works now.
Thanks a lot.

I concur.  Tested on a 2016 MacBook Pro with dual GPUs

This issue was migrated from crbug.com/chromium/1233888?no_tracker_redirect=1

[Multiple monorail components: Blink>Canvas, Blink>WebGL]
[Monorail blocked-on: crbug.com/chromium/1167246]
[Monorail mergedwith: crbug.com/chromium/1233886, crbug.com/chromium/1233887]
[Monorail components added to Component Tags custom field.]