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

Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs



The editor's draft spec does need to be clarified to indicate that the
WebGL reserved prefixes apply, like the "gl_" reserved prefix, to
entry points like bindAttribLocation and getAttribLocation. Unless
there are any objections, I will make this change and push to have it
incorporated into the 1.0.2 spec.

Unreserving the "_webgl_" prefix would make it so that the 1.0.1 tests
no longer run on a 1.0.2-compliant WebGL implementation, cause
incompatibility with the existing 1.0 and forthcoming 1.0.1 specs, and
require another change to the 1.0.2 spec in the process of
ratification. While I agree that in hindsight it was not necessary to
reserve the "_webgl_" prefix in addition to "webgl_", I don't think it
is worth the effort or confusion to change this now. Jeff, if you feel
strongly about this, then please organize a formal vote in the working
group.

-Ken



On Wed, Feb 27, 2013 at 12:03 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> Leaving it up to the tests is terrible, doubly-so if the spec doesn't mention this. This is clearly a tradition we should ignore.
>
> That we're talking about it now makes it clear it should be clearly specified.
>
> -Jeff
>
> ----- Original Message -----
> From: "Gregg Tavares" <gman@google.com>
> To: "Jeff Gilbert" <jgilbert@mozilla.com>
> Cc: "Kenneth Russell" <kbr@google.com>, "public webgl" <public_webgl@khronos.org>
> Sent: Tuesday, February 26, 2013 6:59:58 PM
> Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs
>
>
> I don't have a problem dropping "_webgl_". I think we should keep "webgl_" as is
>
>
>> The spec cannot be vague about these things. Tests match the spec, not vice versa.
>
>
> There are places in the OpenGL ES spec that effectively say "up to the tests" :-(
>
>
>
>
>
> On Tue, Feb 26, 2013 at 6:52 PM, Jeff Gilbert < jgilbert@mozilla.com > wrote:
>
>
> "This is how it's been done" isn't a good reason by itself. The "_webgl_" prefix seems entirely unnecessary.
>
> And still, calling bindAttribLocation *always* drops things on the floor if they aren't used in the linked shader, which /_?webgl_.*/ currently can't ever be. It's not as if extensions are silently added in WebGL either, since you have to opt in to them.
>
> Certainly even if we want to keep "webgl_" reserved, we should clearly state that this will emit an error in bindAttribLocation. The spec cannot be vague about these things. Tests match the spec, not vice versa.
>
> I see no good reason why we should not remove the restriction on "_webgl_", and as such, we should allow it.
>
> I will also strongly note that this has *not* been "the tested behavior for WebGL implementations
> for some time", given that it was only added in 1.0.2, which we are only just now snapshotting.
>
>
> -Jeff
>
> ----- Original Message -----
> From: "Kenneth Russell" < kbr@google.com >
> To: "Gregg Tavares" < gman@google.com >
> Cc: "Jeff Gilbert" < jgilbert@mozilla.com >, "public webgl" < public_webgl@khronos.org >
>
>
> Sent: Tuesday, February 26, 2013 6:26:55 PM
> Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs
>
> On Tue, Feb 26, 2013 at 6:17 PM, Gregg Tavares < gman@google.com > wrote:
>>
>>
>>
>> On Tue, Feb 26, 2013 at 4:47 PM, Jeff Gilbert < jgilbert@mozilla.com > wrote:
>>>
>>> We do inherit GL's behavior, but there's no reason to expand WebGL's
>>> behavior here without reason, nor should we just s/gl/webgl/ everything.
>>> Since restricting it here goes further than what GL mandates, and it doesn't
>>> win us anything, it seems unnecessary to restrict this.
>>
>>
>> Why do you think GL stops "gl_" on bindAttribLocation? By your logic (which
>> I agree with) it could just drop those on the floor as well right? I've
>> assumed there was a reason.
>>
>> If I had to guess I'd guess so they can later add some special
>> "gl_specialAttribThingy" and let you call glBindAttribLocation(prg, index,
>> "gl_specialAttribThingy") to bind it to a specific attribute. If they didn't
>> preemptively reject it in bindAttribLocation then there's the possibility
>> someone is passing that in already which would be silently ignored and then
>> someday suddenly not silently ignored?? So, I've assumed we should do the
>> same for our reserved prefixes.
>
> I agree. This has been the tested behavior for WebGL implementations
> for some time and I see no reason to relax or change it.
>
>
>> As for _webgl_ I'm pretty sure that comes from the discussion group. No idea
>> why
>>
>> http://www.khronos.org/webgl/public-mailing-list/archives/1003/msg00095.html
>
> I think Cedric's idea at the time was that an extension might expose a
> variable "webgl_foo" to shaders that developers were supposed to be
> able to access. (At the time, we were talking about exposing a
> synthetic "webgl_InstanceID" variable.) Identifiers starting with
> "_webgl_" would be used only by implementations. Again, I do not think
> the reservation of these namespaces should be changed.
>
> -Ken
>
>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Further, s/gl/webgl/ here would only add the reserved "webgl_" prefix. I'm
>>> not sure why we reserve "_webgl_".
>>>
>>> -Jeff
>>>
>>>
>>> ----- Original Message -----
>>> From: "Kenneth Russell" < kbr@google.com >
>>> To: "Jeff Gilbert" < jgilbert@mozilla.com >
>>> Cc: "public webgl" < public_webgl@khronos.org >, "Gregg Tavares"
>>> < gman@google.com >
>>> Sent: Tuesday, February 26, 2013 3:29:30 PM
>>> Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs
>>>
>>> The manual page for glBindAttribLocation states:
>>>
>>> GL_INVALID_OPERATION is generated if name starts with the reserved
>>> prefix "gl_".
>>>
>>> WebGL's corresponding entry point should behave the same for WebGL's
>>> reserved prefixes, not silently drop the call on the floor.
>>>
>>> -Ken
>>>
>>>
>>>
>>> On Tue, Feb 26, 2013 at 3:17 PM, Jeff Gilbert < jgilbert@mozilla.com >
>>> wrote:
>>> > I don't see why it's needed, though. The WebGL impl can easily just drop
>>> > these bindings on the floor, since there's no possible time when they'd be
>>> > valid. (All shaders containing them should fail to link, presumedly)
>>> >
>>> > I don't see a good reason for keeping this restriction in light of how
>>> > easy it should be to just ignore such calls. Failing that, we should clarify
>>> > the language, yes.
>>> >
>>> > -Jeff
>>> >
>>> > ----- Original Message -----
>>> > From: "Kenneth Russell" < kbr@google.com >
>>> > To: "Gregg Tavares" < gman@google.com >
>>> > Cc: "Jeff Gilbert" < jgilbert@mozilla.com >, "public webgl"
>>> > < public_webgl@khronos.org >
>>> > Sent: Tuesday, February 26, 2013 2:39:35 PM
>>> > Subject: Re: [Public WebGL] bindAttribLocation on _?webgl_ attribs
>>> >
>>> > Yes, that's correct.
>>> >
>>> > It wouldn't be acceptable if the application developer could call
>>> > bindAttribLocation passing in an identifier starting with one of the
>>> > reserved prefixes and have that apply to an attribute allocated
>>> > internally by the WebGL implementation.
>>> >
>>> > Should this sentence be clarified and perhaps separated out into a
>>> > separate subsection which can be referred to independently of
>>> > "Supported GLSL Constructs"?
>>> >
>>> > -Ken
>>> >
>>> >
>>> >
>>> > On Tue, Feb 26, 2013 at 2:01 PM, Gregg Tavares < gman@google.com > wrote:
>>> >> If the WebGL spec is not clear it should be updated. It's trying to
>>> >> match
>>> >> the OpenGL ES spec but add a prefix. Everywhere "gl_" is disallowed
>>> >> WebGL
>>> >> also wants to disallow "webgl_"
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Feb 26, 2013 at 1:11 PM, Jeff Gilbert < jgilbert@mozilla.com >
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> The test suite has this:
>>> >>> gl.bindAttribLocation(program, 0, 'webgl_a') expected:
>>> >>> INVALID_OPERATION
>>> >>> gl.bindAttribLocation(program, 0, '_webgl_a') expected:
>>> >>> INVALID_OPERATION
>>> >>>
>>> >>> I don't see where this is in the spec. The GLES2 spec has this
>>> >>> behavior
>>> >>> for attribs starting with 'gl_', but I can't find the language in the
>>> >>> WebGL
>>> >>> spec which amends this. It seems like this shouldn't be strictly
>>> >>> necessary
>>> >>> anyways, since we already have this language in the spec:
>>> >>>
>>> >>> "In addition to the reserved identifiers in the aforementioned
>>> >>> specification, identifiers starting with "webgl_" and "_webgl_" are
>>> >>> reserved
>>> >>> for use by WebGL. A shader which declares a function, variable,
>>> >>> structure
>>> >>> name, or structure field starting with these prefixes must not be
>>> >>> allowed to
>>> >>> load."
>>> >>>
>>> >>> With this restriction, it seems that the user couldn't declare an
>>> >>> attrib
>>> >>> with such a name anyways, so bindAttribLocation with these prefixes
>>> >>> would
>>> >>> always do nothing to a shader which meets this restriction, while
>>> >>> refusing
>>> >>> to 'load' (link? use? This should probably be clarified as well.)
>>> >>> shaders
>>> >>> which conflict with this passage.
>>> >>>
>>> >>> It seems like we don't need this restriction, so it should be removed.
>>> >>> Is
>>> >>> there something I'm missing?
>>> >>>
>>> >>> -Jeff
>>> >>>
>>> >>> -----------------------------------------------------------
>>> >>> 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
>>> >>> -----------------------------------------------------------
>>> >>>
>>> >>
>>
>>
>

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