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

Re: [Public WebGL] Depth+stencil extension

On 2010-04-02, at 3:01 PM, Kenneth Russell wrote:

On Fri, Apr 2, 2010 at 6:05 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Apr 1, 2010, at 5:04 PM, Kenneth Russell wrote:

On Thu, Apr 1, 2010 at 4:41 PM, Chris Marrin <cmarrin@apple.com> wrote:

So we believe the problem with failing tests on the WebKit build bots has to do with the fact that many are headless servers and are therefore using the software OpenGL driver, which does not support the depth+stencil extension.

This makes me think that we should only fail to create a context on such systems when they actually ask for both a depth and stencil buffer. That will allow most tests to continue to run on headless systems and will allow us to carefully segregate tests that use both so they can be skipped when we detect that the test machine does not support it.

This raises the question of letting the author know about such situations. Is there a way today that an author can know that the reason a context was not created was because it has depth+stencil? I hope we don't force authors to first try depth+stencil and then depth only just in case that's why it failed.

The problem isn't with the creation of the WebGL back buffer; we can
always ignore the request for a stencil buffer and still be spec
compliant. The issue is that WebGL (and OpenGL ES 2.0) require that
client code be able to create a framebuffer object (FBO) and attach
both depth and stencil renderbuffers. FBO support isn't optional in
WebGL or OpenGL ES 2.0.

On desktop GL, to the best of my knowledge, using the
EXT_packed_depth_stencil extension is the only widely supported way of
attaching both depth and stencil renderbuffers to an FBO. If this
extension isn't available, then if user code happens to use
framebuffers and try to create a depth+stencil renderbuffer, the call
will fail with an OpenGL error. I don't think this is an acceptable
failure mode. If we return a non-null context from
getContext("webgl"), then it needs to support all of the core
functionality. Therefore unfortunately, if we're running on desktop
OpenGL and EXT_packed_depth_stencil isn't available, I think we need
to refuse to run any WebGL content.

And I  think that's much too harsh. We should somehow fail gracefully when an attempt is made to create and unsupported combination of depth and stencil. If this is not OpenGL ES spec compliant then we should describe thoroughly how the behavior differs and make sure it returns enough information to the authors so they can understand how to proceed. I don't think the fact that it's not possible to create an FBO with both a depth and stencil buffer should prevent ANY WebGL from running.

I agree with you that it would be better to run at least some WebGL
content on such devices rather than none.

After rereading the section in the OpenGL ES 2.0 spec on framebuffer
objects and completeness, it sounds like from a strict standpoint, if
an OpenGL ES 2.0 implementation supports just a color renderbuffer or
texture FBO attachment (and no other attachments, for example depth or
stencil), then it is allowed to return FRAMEBUFFER_UNSUPPORTED from
CheckFramebufferStatus() for any other configurations.

Is that correct? Mark Callow or others from the ES working group, is
this legal (if poor) behavior?

My understanding is that both the Desktop OpenGL and OpenGL ES specs allow implementations to fail pretty much *any* FBO combination they don't like with the FRAMEBUFFER_UNSUPPORTED error.   With desktop GL apps this often means that your code needs to have the ability to iterate over a number different color + depth (+stencil) combinations to be able to find a configuration to match what it needs.  (eg some implementations only support 24/32-bit depth with 32-bit color, 16-bit depth with 16-bit  color, etc).

Basically, the question is whether the majority of ES 2.0
implementations today support all of the FBO attachment combinations
color, color+depth, color+stencil, and color+depth+stencil. If they
don't, then there is basically no issue. If they do, then we should
specifically mention in the Differences section of the WebGL spec that
WebGL implementations may have less support of certain framebuffer
attachment combinations than is implied by the OpenGL ES 2.0

I'm not familiar with enough ES 2.0 implementations to know what is commonly supported there, but I do note that there is an OES version of the packed_depth_stencil extension (http://www.khronos.org/registry/gles/extensions/OES/OES_packed_depth_stencil.txt) so I suspect that extension would likely be used on ES implementations which want to support color+depth+stencil.

Hope this helps,

      Daniel Koch -+-  daniel@transgaming.com 
Graphics Technology Lead -+- TransGaming Inc.  -+- www.transgaming.com