[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Depth+stencil extension
On Fri, Apr 2, 2010 at 6:05 AM, Chris Marrin <email@example.com> wrote:
> On Apr 1, 2010, at 5:04 PM, Kenneth Russell wrote:
>> On Thu, Apr 1, 2010 at 4:41 PM, Chris Marrin <firstname.lastname@example.org> 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?
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
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: