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

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



On Sun, Jun 5, 2011 at 8:17 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> 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

OK, I've updated the section on out-of-range array accesses,
incorporated some wording on array indexing expressions into the
section on supported GLSL constructs, and removed the separate section
on dynamic indexing of arrays.

Please review.

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