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

Re: [Public WebGL] Shader validation and limitations



On Fri, Jun 18, 2010 at 11:51 AM, Oliver Hunt <oliver@apple.com> wrote:
> I thought we had agreement a long time ago that WebGL 1.0 would enforce the _minimum_ requirements of a GL|ES implementation, both to reduce the scope for validation, and to try and maximise compatibility across devices.
>
> There are plenty of devices for which
> while(1) ...;
>
> Won't compile as the GPU  doesn't support actual back branches.

The working group did agree to enforce the minimum requirements
defined in Sections 4 and 5 of Appendix A of the GLSL ES
specification. Your additions to
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#SUPPORTED_GLSL_CONSTRUCTS
codify the decision. We decided not to limit WebGL implementations to
only exposing, for example, 8 texture units.

The GLSL ES shader translator / validator does need to be modified to
enforce these restrictions. We need to schedule this work and complete
it before compliant WebGL 1.0 implementations ship, but I don't think
that should prevent incorporation of the shader validator in its
current form.

As has been demonstrated elsewhere in this thread, enforcing these
restrictions does not solve the problem of shaders taking an unusably
long time to run. This problem will need to be addressed at a lower
level, likely by the operating system or graphics driver, although
safeguards like safe browsing can help prevent this content from
running at all on most users' machines.

-Ken

> --Oliver
>
> On Jun 17, 2010, at 5:02 PM, Chris Marrin wrote:
>
>>
>> If you look at section A.4 of the SLES spec:
>>
>>       http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
>>
>> you'll see the minimal requirements of GLSL ES shaders, specifically control flow. I think we should adopt these rules in their entirety. It will not ensure that all shaders are safe, but it will avoid obvious mistakes like infinite loops. It also reduces the floorplan of the shader language a bit to make it easier to to do a better job of validation.
>>
>> I also like Vlad's suggestion of restricting loop indices to ints (as opposed to ints plus floats). This will allow us to accurately determine the number of iterations a for loop will perform so we can choose to reject those that go over some limit.
>>
>> I believe this solves the halting problem issue, (although I suspect Ken disagrees with me). But doesn't necessarily prevent a shader from running for an extremely long time, which I suppose is the same thing in most cases.
>>
>> I think we should be as restrictive as possible in the first release. It is much easier to relax restrictions than to tighten them.
>>
>> -----
>> ~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:
>>
>
>
> -----------------------------------------------------------
> 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: