[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Updated WebGL spec with bounds checking info
On Fri, Jun 3, 2011 at 1:53 PM, Chris Marrin <email@example.com> wrote:
> On Jun 2, 2011, at 10:57 AM, Kenneth Russell wrote:
>> On Thu, Jun 2, 2011 at 9:21 AM, Chris Marrin <firstname.lastname@example.org> wrote:
>>> On Jun 1, 2011, at 3:46 PM, Kenneth Russell wrote:
>>>> On Thu, May 26, 2011 at 11:18 AM, Chris Marrin <email@example.com> wrote:
>>>>> I've just added two new sections to the WebGL editor's draft:
>>>>> 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.
>>>> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: