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

Re: [Public WebGL] Updated WebGL spec with bounds checking info




On Jun 3, 2011, at 2:08 PM, Kenneth Russell wrote:

> On Fri, Jun 3, 2011 at 1:53 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> 
>> On Jun 2, 2011, at 10:57 AM, Kenneth Russell wrote:
>> 
>>> On Thu, Jun 2, 2011 at 9:21 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>> 
>>>> On Jun 1, 2011, at 3:46 PM, Kenneth Russell wrote:
>>>> 
>>>>> On Thu, May 26, 2011 at 11:18 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I've just added two new sections to the WebGL editor's draft:
>>>>>> 
>>>>>>        https://www.khronos.org/registry/webgl/specs/latest/#4.5
>>>>>>        https://www.khronos.org/registry/webgl/specs/latest/#6.20
>>>>>> 
>>>>>> Please review for accuracy and clarity...
>>>>> 
>>>>> There are a couple of inaccuracies and grammatical errors in Section
>>>>> 4.5 (Out-of-Range Array Accesses). Here is a suggested rewrite of the
>>>>> first paragraph:
>>>>> 
>>>>> """
>>>>> Shaders must not be allowed to read or write array elements that lie
>>>>> outside the bounds of the array. This includes any variable of array
>>>>> type, as well as vector or matrix types such as <code>vec3</code> or
>>>>> <code>mat4</code> when accessed using array subscripting syntax. If
>>>>> detected during compilation, such accesses may generate an error and
>>>>> prevent the shader from compiling. Otherwise, at runtime they may
>>>>> return a constant value (such as 0), or the value at any valid index
>>>>> of the same array.
>>>>> """
>>>> 
>>>> This is fine except I think we need to make it clear that the error needs to be generated somewhere.
>>> 
>>> What about saying "If detected during compilation, such accesses must
>>> generate an error..."?
>> 
>> I don't think we need to go that far. It's sufficient to just say something like "The error may be generated during compilation or runtime, but the error must be generated.
> 
> This doesn't work. In the case that static analysis was unable to
> prove that an out of range access will occur, then no error will be
> produced, either at compile time or run time. In the worst case, any
> guards that are injected into the shader source by the WebGL
> implementation will prevent the out-of-range access from occurring. No
> error will be generated.

Ok, that's true. I think your wording is fine then.

> 
>>>>> 
>>>>> Section 6.20 (Dynamic Indexing of Arrays) is redundant; all of its
>>>>> restrictions are already covered in Section 4.3 (Supported GLSL
>>>>> Constructs), since Section 4.3 specifically references the array
>>>>> indexing limitations in Appendix A of the GLSL ES spec. There are also
>>>>> some differences in terminology between this section and GLSL ES'
>>>>> Appendix A. This section should just be removed. I don't think any
>>>>> additional text is needed in Section 4.3. The links from Section 4.5
>>>>> to the Dynamic Indexing section can just be retargeted to Section 4.3.
>>>>> 
>>>>> Are there any objections to making the above changes? If not, and if
>>>>> Chris is too busy, I'll update the spec.
>>>> 
>>>> 6.20 is somewhat redundant. But I think it's important to make it clear what you can and can't do with array indexing. The ES spec is pretty obtuse and I don't think this is explained clearly enough there. But maybe I'm just being pedantic.
>>> 
>>> I think we should instead just clarify Section 4.3 in this case. We
>>> could add three bullet points describing specifically what it means
>>> not to exceed the minimum functionality:
>>> 
>>>  * (Existing sentence about no desktop GLSL constructs)
>>>  * For loops must conform to structural restrictions
>>>  * Only mandated forms of indexing expressions are supported. All
>>> other forms are forbidden.
>>> 
>>> Would this be acceptable?
>> 
>> I think it would be better to be more clear about the indexing restrictions. Maybe we could lift a sentence or two from the deleted section to declare what those "mandated forms" are?
> 
> I'm not comfortable with the current wording in Section 6.20 because
> it uses different wording than that in the GLSL ES spec. It would be
> fine with me to reference the term "constant-index-expression" from
> the GLSL ES spec, and replicate some of the statements about the
> supported forms of indexing.

That sounds fine

-----
~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:
unsubscribe public_webgl
-----------------------------------------------------------