Re: [Public WebGL] Restricting WebGL exposure of OES_depth_texture

[Gregg Tavares (社用) <gman@google.com>]

On Tue, Jun 5, 2012 at 1:11 PM, Kenneth Russell <kbr@google.com> wrote:

On Tue, Jun 5, 2012 at 12:42 PM, Gregg Tavares (社用) <gman@google.com> wrote:
>
>
> On Tue, Jun 5, 2012 at 12:37 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>
>> On Tue, Jun 5, 2012 at 9:29 PM, Gregg Tavares (社用) <gman@google.com>
>> wrote:
>>>
>>> In trying to implement this I'm running into issues
>>>
>>> #1) it looks like we'll need to restrict depth textures to level 0 only.
>>>
>>> Reason: WebGL requires that we clear textures. Otherwise you could
>>> potential read uninitialized memory.
>>> We can clear a depth texture by attaching to an FBO and calling glClear
>>> but we can only attach to level 0
>>> in OpenGL ES 2.0 which means it's impossible to clear levels > 0.
>>
>> I think that's fine, you can also only render to level 0 to other textures
>> unless you have that other extension. Afaik the oes depth texture extension
>> makes no mention that you should be able to render to level 1 and upwards.
>>
>>>
>>> #2) What should we do about GL_DEPTH_STENCIL format?
>>>
>>> WebGL requires support for GL_DEPTH_STENCIL as a renderbuffer format.
>>>
>>> It seems like it also needs to require support for GL_DEPTH_STENCIL as a
>>> texture format for WEBGL_depth_texture
>>> otherwise it's possible you can't use stencils with depth textures.
>>>
>>> I'm not sure what issues that brings up.
>>
>> I don't think it is required that any combination of things you attach to
>> an FBO does work. Some combinations will fail (they're also failing right
>> now). It is required that at least some combination allows you to render to
>> a stencil, depth and color buffer, but unless you try and validate the FBO,
>> you're not gonna know.
>
>
> It's not required. The question is do we want to support stencils at all
> used with depth textures? IIRC Desktop GLs don't support creating a separate
> depth and stencil and attaching both. The only way to get both depth and
> stencil at the same time is to use DEPTH_STENCIL. So, if we don't add
> DEPTH_STENCIL support to WEBGL_depth_texture then there will effectively be
> no way to use a stencil with a depth texture. Of course maybe my memory is
> bad. I thought that's why we added DEPTH_STENCIL in the first place to WebGL
> but I could be remembering incorrectly.

I recall the reason for adding the DEPTH_STENCIL attachment point to
WebGL was twofold: first, this is the direction the OpenGL spec had
taken; and second, it was too difficult to emulate the behavior of
separate vs. packed depth and stencil attachments on top of the other
functionality. (OpenGL ES 2.0 devices supported separate
depth/stencil, but desktop platforms only supported packed
depth/stencil.)

Anyway, it looks like GL_OES_packed_depth_stencil is actually the
extension that adds depth-stencil support to GL_OES_depth_texture.
See:

http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt
http://www.khronos.org/registry/gles/extensions/OES/OES_packed_depth_stencil.txt

In sum, it looks like a packed depth/stencil extension could be added
to the WebGL extension registry later, and have it modify the behavior
of WEBGL_depth_texture, like in the OES specs. What do you think?

There's no reason to ever add OES_packed_depth_stencil to WebGL since WebGL already effectively requires it. Hence why I brought this up. Since WebGL already requires the same behavior as OES_packed_depth_stencil that kind of implies that WEBGL_depth_texture should support DEPTH_STENCIL formats.

 

Florian, do you know (or could you find out) how many devices support
OES_packed_depth_stencil? Looks like it's well supported on iOS, at
least (http://www.lastrayofhope.com/2011/07/24/ios-opengl-es-extension-support/
).

-Ken