after several webGL crash + update, fallback in webGL1.0
Reported by
fabrice....@gmail.com,
Nov 11 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Example URL: uneasy to reproduce and tedius to freeze again and again, but here is a good start: https://www.shadertoy.com/results?query=%5BSH16C%5D Steps to reproduce the problem: 1. trying loading several big full fragment shader game (or just browsing) 2. sometime the browser stall, webGL crash, and offer to update (thus restarting webGL) 3. sometime webGL restart in webGL1.0 instead of 2.0 What is the expected behavior? always restarting in webGL2.0 What went wrong? sometime restarting in webGL1.0 (many shaders preview no longer displayable). Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? N/A Chrome version: 62.0.3202.89 Channel: stable OS Version: ubuntu 14.04 Flash Version: Shockwave Flash 27.0 r0 sorry it's not possible to give a straighter acid test. May somebody please set flags Blink>WebGL , Internals>GPU ? ( Am I supposed to be able to do this somewhere ?)
,
Nov 13 2017
what do you mean by crash ID ? Beside, when webGL crash, chrome doesn't crash (contrarily to firefox). Chrome just propose to either ignore or update/reload. Usually all is restored correctly, but sometime it restarts in webGL1 instead of webGL2.
,
Nov 13 2017
Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 13 2017
,
Nov 13 2017
This is working as intended. If Chrome's GPU sub-process crashes multiple times in a row -- for example, because of a GPU hang, which seems to be what https://www.shadertoy.com/results?query=%5BSH16C%5D provokes on some hardware -- then it deliberately blacklists all GPU functionality, including WebGL. Chrome's then falling back to the SwiftShader software renderer for its WebGL rendering, and currently it's set up to only support WebGL 1.0. Do you want it to support WebGL 2.0, though more slowly than the GPU? Allowing Chrome to continue to use the GPU without further user intervention is not a viable option due to the possibility of denial-of-service attacks.
,
Nov 14 2017
Oh, I didn't suspected it was a software fallback ! Anyway, after a webGL crash a popup asks be if I want to restart or not (I don't know if Chrome or Shadertoy site sent it). So when I click "update" rather than "ignore", I'm supposed to know what I'm doing. Beside, a 3rd option could be "fallback to emulator". In a web context, we have often have several chrome tabs and windows open. One tab may have crashed the GPU multiple time (for shadertoy it's often a shader too long or with too big arrays ), but this has no reason to impact what is allowed in other tabs as this ban strategy is doing !
,
Nov 16 2017
It's not technically feasible on most platforms to accurately determine which tab using WebGL might have caused the GPU to hang and/or the underlying OpenGL / ES / Direct3D context to be lost. For this reason, all tabs that were using WebGL are banned from using the API further without explicit user interaction. We will be changing the user interface around this in Issue 575305 . That is close to being implementable, with the removal of Chrome's old navigation code. I'm sorry, but I'm closing this as WontFix. The mechanism is working as intended. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by vamshi.k...@techmahindra.com
, Nov 13 2017Labels: Needs-Feedback Triaged-ET Needs-Triage-M62