WebGL2: gl.getParameter(gl.MAX_CLIENT_WAIT_TIMEOUT_WEBGL) returns 0
Reported by
rakber...@zynga.com,
Dec 11
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36 Steps to reproduce the problem: 1. obtain a WebGL2RenderingContext as the variable gl 2. type gl.getParameter(gl.MAX_CLIENT_WAIT_TIMEOUT_WEBGL) into the console What is the expected behavior? The value returned is greater than 0 and less than 16000 nanoseconds (max is debatable but recommended to not exceed 100ms by the KhronosGroup in their conformance github code). Admittedly the conformance code would allow 0 as a valid number. What went wrong? The number is 0. Did this work before? N/A Chrome version: 70.0.3538.102 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: This number is the max number of nanoseconds that the blocking call "gl.clientWaitSync()" will wait before returning a status of gl.TIMEOUT_EXPIRED. As it is currently set to 0, it will expire almost instantly. The context of this problem is with waiting for the gpu to finish its conditions (usually gl.SYNC_GPU_COMMANDS_COMPLETE) before accessing buffers.
,
Dec 11
rakberdin@ Thanks for the issue. Request you to provide a sample file/URL, where this issue can be reproduced, which will help in further triaging. Thanks..
,
Dec 11
The 0 value was hardcoded since r193222 ( bug 295792 ). I think this issue should be set to untriaged in "Blink>WebGL" component.
,
Dec 11
,
Dec 11
I agree about the component should be WebGL related. Here is a js fiddle with the repro: https://jsfiddle.net/u5680ba7/ You will need to look at the js console for printouts to console.log() I think js fiddles can expire so I will attach the code as a file as well. If the repro is not sufficient I can add more.
,
Dec 11
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
,
Dec 11
Just want to say my initial figure of 16000 nanoseconds was just a ballpark and it should probably be closer to 33333 for software rendering at 30fps at the slowest.
,
Dec 12
,
Dec 12
This is as intended. Applications should have no need to call clientWaitSync in WebGL 2.0 in order to synchronize the CPU and GPU, and are forbidden in Chrome from blocking the JavaScript main thread via this API. There are no mapBuffer APIs in WebGL 2.0; the primary ways to upload data to buffers are via bufferData and bufferSubData, and the only ways to read back data are readPixels or getBufferSubData. If you're trying to avoid stalls when calling getBufferSubData, use waitSync, not clientWaitSync.
,
Dec 12
Alright I understand. Thanks for the additional note on waitSync. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by rakber...@zynga.com
, Dec 11