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

Re: [Public WebGL] Proposal for depth and stencil FBO attachments

On Feb 25, 2010, at 7:54 PM, Kenneth Russell wrote:

> On Thu, Feb 25, 2010 at 6:19 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> On Feb 25, 2010, at 11:28 AM, Kenneth Russell wrote:
>>> There is a problem implementing the current WebGL (and OpenGL ES) semantics for depth and stencil attachments to framebuffer objects on desktop OpenGL. On the desktop, the best supported functionality for adding a stencil buffer to an FBO is to use EXT_packed_depth_stencil. The renderbuffer is allocated with the GL_DEPTH_STENCIL or GL_DEPTH24_STENCIL8 format and is attached to both the GL_DEPTH_ATTACHMENT and GL_STENCIL_ATTACHMENT points of the framebuffer. Separate depth and stencil renderbuffer attachments to FBOs are not well supported.
>>> On OpenGL ES, the only functionality guaranteed to be supported is separate depth and stencil attachments, though there is a GL_OES_packed_depth_stencil extension.
>>> Because of how renderbuffers are allocated and attached to FBOs, it is very difficult to emulate the behavior of separate depth and stencil attachments when the underlying platform only supports packed depth and stencil. However, it is easy to emulate the behavior of packed depth and stencil attachments when the underlying platform only supports separate attachments. The reason is that at the point glRenderbufferStorage is called with the packed format, a hidden second renderbuffer can be generated and allocated. There is no good place to do this if the separate depth and stencil renderbuffers are exposed in the public API; glFramebufferRenderbuffer is the best interposition point, but it is a poor one.
>>> To make it feasible to implement stencil buffer support for FBOs on all platforms I would like to propose the following specification changes.
>>> 1. Add the enum DEPTH_STENCIL (0x84F9), which is accepted as the internalformat parameter of renderbufferStorage.
>>> 2. Add the enum DEPTH_STENCIL_ATTACHMENT (0x821A) from OpenGL 3, which is accepted as the attachment parameter of framebufferRenderbuffer.
>>> 4. State that it is an error to attach the same renderbuffer to both the DEPTH_ATTACHMENT and DEPTH_STENCIL_ATTACHMENT attachment points of a framebuffer object.
>>> 5. Add a subsection to the spec describing the difference in behavior compared to OpenGL ES 2.0.
>> I'm fine with changes like this. But I don't understand why we can't do it all under the covers. If you specify separate depth and stencil renderbuffers, can't we internally combine them if needed? Alternatively, if the implementation requires it, can't we ALWAYS just allocate a packed stencil/depth buffer and just ignore one of the attachment calls if both are made? For instance, when a renderbuffer is created as depth or stencil, we can defer the actual creation of the buffer. When one is attached, we can create a depth/stencil buffer and attach that. When the other is attached, we can just ignore it.
> It will be very difficult to hide from the programmer that calls to
> renderbufferStorage are being deferred. As only one example, we would
> have to synthetize results to calls like
> getRenderbufferParameter(RENDERBUFFER_WIDTH). It will also be
> difficult to precisely emulate the semantics of detaching a
> renderbuffer from one FBO and attaching it to another.
> It might be possible to do the trick you suggest of always allocating
> packed depth/stencil renderbuffers on the desktop. I believe this is
> still likely to backfire, however. Unless we can successfully defer
> allocation of renderbuffers, then both the depth and stencil
> renderbuffers would have to have real storage allocated during the
> renderbufferStorage call, and again, we would not be able to precisely
> emulate the semantics of detaching a renderbuffer from one FBO and
> attaching it to another. (Consider the case where you render into the
> FBO, then detach the stencil attachment and attach it to a different
> FBO.)
>> I haven't thought about all the implications, but I'd like to use an approach where we don't have to change the spec from the author's standpoint. But if necessary, the rule changes you specify seem fine.
> The differences in behavior in this area between OpenGL and OpenGL ES,
> and between OpenGL and Direct3D, make the OpenGL ES semantics very
> difficult to emulate. It would be far simpler to choose a different
> set of semantics which can be easily emulated on OpenGL ES.

Ok, then I agree that we should come up with semantics that can be emulated on all three styles of rendering libraries (OpenGL, GL ES, and D3D). But do we need to get rid of the stencil enums? Can't we just say that you can have one and only one of { depth, stencil, depth_stencil }? In other words, remove your rule 3 and change rule 4 to include STENCIL_ATTACHMENT. Again, I have no problem with getting rid of bare stencils in the spec, but only if there is no other way. There will be some implementations that will be able to optimize memory usage better if they know the author just wants a stencil buffer.


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: