filament
filament copied to clipboard
google
Under Mac Chrome, the official demo blocks the browser for up to 3 seconds.
Describe the bug Under Mac Chrome, the official demo blocks the browser for up to 3 seconds.
To Reproduce You can reproduce this problem by opening the official web page.
When you open the official page, a lag occurs for a few seconds, during which any action of the browser hangs, including switching tabs. this lag time seems to increase with the complexity of the shader. In my own application, which has about 10 shaders, this lag time lasts 30 seconds or more, reaching a state that is completely unacceptable to the user.
I tried some modifications using KHR_parallel_shader_compile, which reduced the time for js execution in the Flame Graph, but still blocked the UI. using off-screen canvas rendering did not improve anything either.
This problem does not occur on windows.
It seems that only filament has this kind of blocking, threejs or other webgl-based engines do not have this problem.
Expected behavior The behavior of mac should be the same as windows.
Screenshots
trace using chrome trace event profiling tool, It seems to be blocking on the CommandBufferProxylmpl::WaitForGetOffset method
Desktop (please complete the following information):
- Device: Retina 5K, 27-inch, 2017
- OS: [Mac OSX 13.2.1 (22D68)]
- Browser: [Chrome version 110.0.5481.177 (x86_64)]
- GPU: [Radeon Pro 580 8 GB]
- Backend: [WebGL(using OpenGL backend in Chrome settings)]
This is a known issue on the Chrome side, and we haven't found a satisfactory workaround (note that Filament uses WebGL2 when three.js uses WebGL for instance).
In fact today, both threejs and babylonjs use webgl2 backends for rendering, and they do not have synchronous UI blocking of more than 2 seconds in any case. Is this related to the order in which filament calls the opengl api? It seems that the blocking all happens on the getXXX method. Are all these calls necessary and can filament maintain state internally instead of calling gl's methods to query state every time?
Here is the key code to initialize webgl for both engines: https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGLRenderer.js#L235 https://github.com/BabylonJS/Babylon.js/blob/d521fd0ce8299552f1ea67c2a2198907f50507a5/packages/dev/core/src/Engines/thinEngine.ts#L921
Actually we're calling the get methods at the last possible time to allow the driver to compile in parallel.
The get is not about state caching, it's about finding out if the compilation succeeded.
What this is, however, is a bug in Chrome. For some reason its compilation time becomes insanely long when using an array in a ubo for instancing, we think the problem happens only on Mac (to that extent at least).
We haven't found a workaround. Even with an instancing array of 1 the times are pretty long.
All state caching is done internally and Filament doesn't use glGet to query the current state.
@pixelflinger Is ubo required in the filament implementation? If it is clear that ubo is causing UI blocking, is there a way to not use this feature on the mac platform?
Is it completely certain that the UBO feature is causing the problem? Since it's a bug in Chrome on MacOS, I wonder if you guys have given any feedback to the chrome team?
Is it completely certain that the UBO feature is causing the problem? Since it's a bug in Chrome on MacOS, I wonder if you guys have given any feedback to the chrome team?
We told them.
Thank you for your answers.
If the chrome team can't solve this problem quickly, is it possible to make some changes to filament, instead of using UBO to pass data, use the traditional glUniform* function to set uniform? For larger arrays pass the data with texture instead and read it in the shader with texelFetch.
We have already tried to mitigate the issue. Currently we don't have a solution because the same material file is used desktop and web.
Actually we're calling the get methods at the last possible time to allow the driver to compile in parallel.
The get is not about state caching, it's about finding out if the compilation succeeded.
What this is, however, is a bug in Chrome. For some reason its compilation time becomes insanely long when using an array in a ubo for instancing, we think the problem happens only on Mac (to that extent at least).
We haven't found a workaround. Even with an instancing array of 1 the times are pretty long.
i have delete all code of instancing, shadowdata, bonedata, anything like that, but it still freeze the bowser about 12 seconds on mac. when i catch the performance, getProgramParameter still be the problem. i run the triangle demo by the way.
https://crbug.com/1348017
It seems that I don't have the permission to view this bug. By the way, is it possible to bypass this issue by using WebGPU instead of WebGL2 as the backend?