[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposal for depth and stencil FBO attachments
On Thu, Feb 25, 2010 at 6:19 PM, Chris Marrin <firstname.lastname@example.org> 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.
>> 3. Remove the enums STENCIL_ATTACHMENT, STENCIL_INDEX and STENCIL_INDEX8.
>> 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
> 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.
>> These changes would move the WebGL spec closer to OpenGL 3's behavior and would be implementable on both desktop GL and OpenGL ES 2.0 without OES_packed_depth_stencil. They would also have the benefit of being easily implementable on top of D3D. They are a subset of OES/EXT_packed_depth_texture and OpenGL 3 functionality.
>> The only downside compared to the current API is the inability to attach a stencil buffer without a depth buffer, which I don't think is important.
> But you can specify a stencil buffer without a depth buffer. Most implementations would just give you both internally, which should be transparent to the outside, right?
> 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:
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: