[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Infinite loops allowed in WebGL 1.0 currently?



On Fri, Mar 6, 2015 at 1:04 PM, Ben Constable <bencon@microsoft.com> wrote:
> We were looking at a bug in IE recently and came across an interesting case:
>
> http://threejs.org/examples/#webgl_materials_parallaxmap
>
> This has this fragment of GLSL code:
>
>                                "for ( int i = 0; i == 0; i += 0 ) {",
>
> This is obviously an infinite loop. I am assuming that the site is working
> because the code is never hit in practice.
>
> The way that we translate GLSL, this is a bit tricky for us. It appears that
> ANGLE is outputting [loop] in HLSL, and on most hardware this will happily
> generate an infinite loop that causes TDRs in the shader (we can make Chrome
> TDR using loop constructs like this).
>
> The specification for loops in GLSL seems to have a lot of effort put into
> preventing unverifiable loops – is the case of a zero increment an oversight
> in the specification? I would love to return an error for this kind of case
> but if I do that now, I will end up not working on a site that works in
> ANGLE based browsers, and this is not good for interoperability.

It looks like the shader more precisely does

  for ( int i = 0; i == 0; i += 0 ) {
    if ( heightFromTexture <= currentLayerHeight ) {
      break;
    }
    currentLayerHeight += layerHeight;
    // ...
  }

GLSL ES 1.0.17 appendix A allows for_headers including the form:

  loop_index += constant_expression

and section 6.3 "Iteration" says

  Non-terminating loops are allowed. The consequences of very long or
non-terminating loops are platform dependent.

so strictly speaking, the shader should validate.

There are surely many shaders using conditional breaks to work around
the lack of dynamic upper bounds in loop conditions. I'm pretty sure
I've seen similar shaders using constructs like

  while (true) {
    if (something)
      break;
    // ...
  }

It would be ideal if we could figure out a solution allowing your GLSL
translator to run these shaders. If the issue is that you
unconditionally unroll loops, can you avoid doing so only in these
problematic situations?

-Ken

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------