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

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



The editor's draft specification has been updated to clarify the
behavioral changes to bindAttribLocation, getAttribLocation and
getUniformLocation:

https://www.khronos.org/registry/webgl/specs/latest/#5.14.9
https://www.khronos.org/registry/webgl/specs/latest/#5.14.10

Please post any comments to the list.

-Ken



On Wed, Feb 27, 2013 at 12:10 PM, Kenneth Russell <kbr@google.com> wrote:
> 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
-----------------------------------------------------------