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

Re: [Public WebGL] WebGL Shader Validation



Now flip down to Appendix A: Limitations for ES 2.0 (p108), where it says (among other things): 
1. OpenGL ES 2.0 implementations are not required to support the full GLSL ES 1.00 specification. ...
...
4. In general, control flow is limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time.

Hope this helps
Daniel

On 2010-06-18, at 12:25 PM, Alan Chaney wrote:

I have the OpenGL ES 2 shader specification 1.00 rev 17 open in front of me:

It says: (Sec  6.3 Iteration pp57)

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


It appears to me that a syntactically correct loop could be:

for ( int i = 0; i < 5; i ++) {

    i = i - 1;

    // whatever else you want to do here...
}


Regards

Alan





On 06/18/2010 09:09 AM, Cauê Waneck wrote:
Another solution could be to only allow loops that can be unrolled at compile time. Couldn't it? I actually thought that OpenGL ES 2.0 specs already had this limitation.

2010/6/18 Chris Marrin <cmarrin@apple.com>

On Jun 17, 2010, at 10:24 PM, Oliver Hunt wrote:

> On Jun 17, 2010, at 6:46 PM, Vladimir Vukicevic wrote:
>
>>
>> ----- "Steve Baker" <steve@sjbaker.org> wrote:
>>
>>> Since there is little or no practical use for shader programs that don't
>>> complete within a very small fraction of a second - a one second (or so)
>>> watchdog timer would seem to be the best - and perhaps only - pragmatic
>>> solution.  We could even allow users to set how long the timer would
>>> wait before killing the web page in some 'about:config' page just in
>>> case they want to use WebGL for some kind of non-traditional use (eg
>>> CUDA-like applications).
>>
>> If we had a way to do this (abort execution while inside a long-running shader), we wouldn't be having this conversation :-)  The problem is that in most cases your entire system is locked up waiting for the GPU to come back; Windows Vista/7 handles this case by forcibly resetting the entire graphics card (and thus killing any contexts), which is probably the best response for now.  But that functionality isn't available to any programs to use directly, and no equivalent exists on other platforms.  Something might happen on that front, but even if it does we need a solution for older (current) driver versions; that solution might be "you don't get to run complex shader programs until you upgrade your drivers", though.
>
> The other issue that exists is that even if the OS was willing to kill off the GPU insanely quickly (say 5ms), i could still write a piece of code that hammered the GPU by restarting the bad shader.  This would (effectively) produce a DoS of the entire machine.

_javascript_ will kick in its timeouts if you do this, so that's not a problem. As long as the GPU can kick the shader in a reasonable amount of time and the damage to the system due to the GPU reset is not unrecoverable, you will be able to get back control of your system.

-----
~Chris
cmarrin@apple.com




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


!DSPAM:4c1b9d49164292117114708!


---
                        Daniel Koch -+- daniel@transgaming.com
Senior Graphics Architect -+- TransGaming Inc.  -+- www.transgaming.com