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

Re: [Public WebGL] some samples and a question about looping



I do not think that WebGL is unrolling your loop.  I think it is entirely to do with the ATI drivers. WebGL does not require unrolling, it merely states that variables cannot be used to terminate loops in fragment shaders.

If your unrolled loop is taking gigabytes of memory, I would worry about its performance when not unrolled, especially on mobile devices.

Regards

-Mark





On 27/12/2010 01:13, Sami Mäkelä wrote:
Ok, it seems to me that on platforms where infinite or otherwise too
long loops in the shader can crash the system,  unrolling should be
forced, or at least the driver should be made check that no such loops
are possible. Hopefully that is already the case in current WebGL
implementations.

Anyway, as you pointed out, the restriction in WebGL (Appendix A.4 in
GLSL ES 1.0 spec) doesn't exclude infinite or too long loops (and also
while-loops can be unrolled by drivers if they have constant number of
iterations). Just like WebGL doesn't enforce other minimum
requirements of ES (for example VTF is allowed), it should not enforce
this one. In fact, this restriction doesn't prevent any unportable
programs, because the loop bound can be selected high enough so that
it won't work on platforms that unroll it. Actually the restriction
can make programs even less portable (for example my Xmas star doesn't
seem to work on ATI GL drivers for Windows 7, it just allocates
gigabytes of memory). I think that the only way to make loops portable
is testing on different platforms, this restriction isn't helping at
all...

-- Sami

On Sat, Dec 25, 2010 at 3:26 PM, Steve Baker <steve@sjbaker.org> wrote:
The WebGL spec requires that GLSL implementations limit themselves to
the MINIMUM OpenGLES2.0 requirements - so we don't allow loops with a
non-constant number of iterations (and we specifically disallow those
where the value of a uniform is used to determine the termination
condition).

In other words, only loops that could (in principle) be unrolled at
compile time are allowed.

I believe that there are two reasons for this - one is that a lot of
hardware doesn't support loops at all - so the compiler is forced to
unroll them.  The other is as a kind of security measure to make sure
the bad guy can't lock up your computer by putting a shader into an
infinite loop.

Now - I agree that there is an issue here...while it's reasonable to
require loops that could in principle be unrolled - should WebGL force
them to actually be unrolled in practice?   Arguably, it shouldn't
because that makes the shader code much longer than it needs to be on
machines that CAN support looping at the hardware level.

I say "arguably" because the current restrictions don't seem to prevent
you from saying something like:

    for ( float i = 100000000 ; i < 100000001 ; i += 0.1 )
      dosomething ;

...which is legal (per the specification) - and on paper, only iterates
10 times.   But in practice, it would probably loop forever because math
precision isn't good enough and 100000000+0.1 evaluates to 100000000, so
the loop never reaches its target.  If loops are not literally unrolled
by the compiler, this kind of infinite looping would be hard to
definitively exclude.

You might imagine that the shader verifier could try unrolling the loop
to make sure it's possible - and if that works, pass on the original
rolled-up loop to the underlying GLSL compiler - but that's awfully
risky if you don't know the precise inner workings of the GPU's floating
point math unit.  The bad guy might easily find a 'chink' in that armor
with carefully-chosen data.

Your work-around of looping a very large number of times and then
breaking out in the middle is legal in principle - but if the compiler
does unroll loops, you'll run out of shader instructions and it won't
compile.

 -- Steve


On 12/24/2010 10:51 AM, Sami Mäkelä wrote:
Hello!

I've updated my samples at http://programming-progress.com/webgl.html
so that they now work (or do not work) as expected on the latest
browsers. At least check out the Xmas star.

One question: It seems like the ATI GL drivers on at least Windows 7
64bit seem to always unfold loops that have constant number of
iterations. My workaround was to force the looping to be unknown (by
using uniforms). This doesn't work anymore because ANGLE validator
doesn't accept it. Is there some example on any platform where
converting the shader code to the form accepted by ANGLE would
actually convert a non-working shader to a shader that works with the
driver?
Anyway even if there is some driver that cannot handle full looping,
it should not matter, because any program can be converted into the
form accepted by ANGLE for example using
while (cond) body; ===> for (int i = 0; i < INFINITY-1; i++) { if
(!(cond)) break; else body; }
As summary, this check might cause some shaders to become impossible
on some environments, and it does not add to compatibility, because
the shaders could be easily converted into form that should be
accepted, if the original code is rejected by the driver. Wouldn't it
just be better to drop this check and say that the loops are "too
long" (and hence undefined) if they are not supported by the driver?

-- Sami
-----------------------------------------------------------
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:



-----------------------------------------------------------
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:
begin:vcard
fn:Mark Callow
n:Callow;Mark
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
email;internet:callow_mark@hicorp.co.jp
title:Chief Architect
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660
x-mozilla-html:TRUE
url:http://www.hicorp.co.jp,  http://www.mascotcapsule.com
version:2.1
end:vcard