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

Re: [Public WebGL] Minor spec updates



Texture swizzling (https://www.opengl.org/registry/specs/EXT/texture_swizzle.txt) allows you to remap any channel (RGBA) to any other channel not as part of a shader command texture2D(foo, bar).bgra but as part of a texture parameter state glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_R_EXT, GL_BLUE).

It's expensive on D3D because D3D doesn't have texture swizzling state parameter functionality. It has been elevated to core functionality in ES 3.0 and GL 3.3.

The idea behind this functionality is to make it easier to handle passing data around in textures. It's based on the observation that if you put data into a texture, you're assuming an implicit semantic as to what channels mean. Swizzle is supposed to make that easier. I personally don't see how it makes that easier.

A more meaningful extension (which doesn't exist) would allow a programmer to define a structure of some kind, and define that a sampler obtains said structure, such that calls like myStructure.sample(someUniform, someUV).albedo become possible. It could be argued this could be introduced as a shader transpiler of some kind.

On Wed, Feb 25, 2015 at 1:35 AM, Kenneth Russell <kbr@google.com> wrote:

It's the swizzle state of texture objects that's been removed. GLSL
swizzles are unaffected.


On Tue, Feb 24, 2015 at 3:23 PM, Ben Adams <thundercat@illyriad.co.uk> wrote:
> This is just parsing swizzles, not GLSL swizzles?
>
>
> On 24 February 2015 at 23:01, Kenneth Russell <kbr@google.com> wrote:
>>
>>
>> It was determined by both the ANGLE team (who have built OpenGL ES on
>> top of Direct3D) and Microsoft's browser team that OpenGL's texture
>> swizzle functionality can not be implemented with high performance on
>> top of Direct3D. There are two primary options for doing so -- either
>> re-uploading texture data behind the scenes -- expensive, as you can
>> appreciate -- or dynamically recompiling shaders on the fly to include
>> the appropriate texture swizzles -- also expensive, and a lot of
>> bookkeeping. Either way, an application heavily utilizing OpenGL ES's
>> texture swizzle functionality would never perform well on a Direct3D
>> based WebGL implementation. For this reason the functionality was
>> removed from WebGL.
>>
>> For use cases like Emscripten, it will be necessary to push back to
>> application authors and re-cast the use of texture swizzles in some
>> other way. There are plenty of other options, including generating new
>> shaders on the fly, or generating several up front at application
>> startup.
>>
>> -Ken
>>
>>
>> On Mon, Feb 23, 2015 at 9:57 PM, Jukka Jylänki <jujjyl@gmail.com> wrote:
>> >
>> > The choice to remove texture swizzles sounds arbitrary to me. Neither
>> > the pull request or this mail actually explain what the hardware for this
>> > was, which leaves the most important bits of detail for a decision like this
>> > up for random guesses to parties who were not present in the F2F discussion.
>> > Why is native GL/GLES then able to implement these, and why is WebGL special
>> > in this respect that it can't?
>> >
>> >> On 24 Feb 2015, at 03:40, Kenneth Russell <kbr@google.com> wrote:
>> >>
>> >>
>> >> A couple of minor spec updates to WebGL 2.0:
>> >>
>> >> - Texture swizzling has been removed from the specification in
>> >> https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL
>> >> implementations, texture swizzles can not be implemented in a
>> >> performant manner, meaning that applications relying on this
>> >> functionality would run significantly more slowly on those
>> >> implementations. For this reason, texture swizzles will not be
>> >> supported in WebGL 2.0.
>> >>
>> >> - A query of the implementation-dependent maximum client wait timeout
>> >> has been added in https://github.com/KhronosGroup/WebGL/pull/871 .
>> >> This is intended to prevent applications from blocking the browser's
>> >> main thread for long periods of time. An INVALID_OPERATION error will
>> >> now be generated if the user requests a timeout larger than the
>> >> maximum.
>> >>
>> >> Please send any comments about these changes to the list.
>> >>
>> >> Thanks,
>> >>
>> >> -Ken
>> >>
>> >> -----------------------------------------------------------
>> >> 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
>> -----------------------------------------------------------
>>
>

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