[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Updated WebGL spec with bounds checking info
- To: Chris Marrin <email@example.com>
- Subject: Re: [Public WebGL] Updated WebGL spec with bounds checking info
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Thu, 2 Jun 2011 10:57:10 -0700
- Cc: public webgl <email@example.com>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307037431; bh=yICChfxXF0ef8bE7DZVsKL6qidQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=XE+TK3gMAYc3t0Qf5i29Y2ueps6789+b6KTqw0tTn1z1YEPJayK8jgGmgY5j/bGGV 8XVTQ+pl/spj20TS6jSfA==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bpNDo6tp07qgqmrHErpgMou8EXAWtsPtrlXBdm99R00=; b=UVGDGmZpHG0BgKYFW5Ah2wLrVkE3qRiAkJJgMg5Gt5bLWY3soVoNDn8nsJBxBaFtcc GQytAztcYUl3R+LRgHOw==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E2FdWd7HDyON6xotJgp1RXv58rdgcE8myzulYHf/I/NkEH6NIOlQllaDXVu9Q4N+iQ DFeiSCNq1K0/cWhHlwMQ==
- In-reply-to: <A02D7A47-E105-47BB-A241-CB66E496F81C@apple.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> <BANLkTi=TWa3v3ciM549DgCHG2V2sJ9ZDJw@mail.gmail.com> <A02D7A47-E105-47BB-A241-CB66E496F81C@apple.com>
- Sender: firstname.lastname@example.org
On Thu, Jun 2, 2011 at 9:21 AM, Chris Marrin <email@example.com> wrote:
> On Jun 1, 2011, at 3:46 PM, Kenneth Russell wrote:
>> On Thu, May 26, 2011 at 11:18 AM, Chris Marrin <firstname.lastname@example.org> 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..."?
>> 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?
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: