WebGL v2 / Chrome crashes during shader compilation

[markus...@googlemail.com]

Hi,

we are working on an SDF (signed distance functions) based modeller at www.raysupreme.com. It uses a PBR based path tracer for rendering and requires WebGL v2.

We, as many others I guess, have problems with crashes / long compile times of the rendering shaders. As the map() function inside the shader gets quite big with larger scenes, and this function is inside the path tracer loop, it looks like there is an aggressive loop unrolling going on during shader compilation. 

The attached test scene crashes Chrome but works fine In Firefox (although compilation time of the shader is about 15 seconds). I guess FF just "waits longer" for the shader compilation to finish while Chrome throws an exception after a few seconds.

My questions:

* Is there a way, or will there be a way, to disable loop unrolling during shader compilation ? We would happily sacrifice performance for being able to safely run the shader, this is non realtime rendering anyway.

* I read somewhere that with WebGL v2 I can actually find out if the shader has finished compiling or not. Anybody has a link how this is done ? This would enable me to wait until shader compilation is finished before using the shader, which may help with the Chrome issue.

* Also, what is the best way to find out how many milliseconds were needed for a given rendering pass ? I did not find a way yet which works in both Chrome and FF. We adjust the number of scanlines to render based on the average time needed per scanline.

Thanks a lot for any help.

Markus

[Kenneth Russell]

Hi Markus,

As discussed on your Chromium bug report http://crbug.com/727071 , the problem here was that the shader was taking so long to compile inside the OpenGL driver that it triggered Chromium's GPU watchdog timeout. The default timeout is set to 10 seconds, and if any GPU related operation takes that long, the browser terminates it to preserve user interactivity. (Firefox doesn't have this timeout, which is why that browser wasn't affected.)

The following two extensions (one for WebGL 1.0 and one for WebGL 2.0) support coarse-grained timing of GPU operations, and are probably the best way for you to see how long scanline rendering is taking. Note that currently Chrome exposes EXT_disjoint_timer_query_webgl2 on WebGL 2.0 contexts while Firefox exposes EXT_disjoint_timer_query; this difference will be ironed out soon.

https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query/

https://www.khronos.org/registry/webgl/extensions/EXT_disjoint_timer_query_webgl2/

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[markus...@googlemail.com]

Hi Kenneth,

thanks for the reply, sorry I was on a small holiday and just returned.

I understand the Chrome problem and we will work around it, I just don't understand why something like the loop unrolling in the OpenGL shader is not configurable somewhere inside WebGL. It seems to affect a lot of people, especially those doing SDFs and procedural content creation.

Thanks for pointing out the extensions, I was not aware of these, will check them out.

-Markus

To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.

[Kai Ninomiya]

Chrome/ANGLE are not performing any loop unrolling. Chrome produces a shader to be sent to the driver, with the original loops. Unfortunately the hardware driver is performing these loop unrolls and there is no way to control this even from within Chrome.

-Kai

[markus...@googlemail.com]

Hi Kai,

thanks for the answer. I did send a message to the Khronos WebGL mailing list too in the vain hope of getting the attention of some of the GLSL driver people. As a lot of people are having problems with this, the more feedback they get the better.

-Markus