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

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






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.

It has been in the 1.0.1 tests though
https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/glsl/misc/shader-with-webgl-identifier.vert.html
https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/glsl/misc/shader-with-_webgl-identifier.vert.html

 

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