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

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




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.

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

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