OpenGL ES 2.x: any way to reuse depth buffer for off-screen and on-screen rendering?

Question

I'm doing 2-pass rendering, where for the first pass I'm rendering to a texture and for the second pass I'm rendering to the screen.

I'm rendering the same polygons in both passes, but I'm using different shaders. In particular, the second pass uses a shader that takes the texture generated by the first pass as a parameter.

Currently my first pass has a framebuffer with a texture for the color attachment and a renderbuffer for the depth attachment (stenciling is disabled), while the second pass renders to the default framebuffer (0).

It occurred to me that since I'm rendering exactly the same polygons in pass-2, the depth buffer will end up looking identical to my pass-1 depth buffer. If I could somehow have the pass-2 depth buffer start out initialized to pass-1's depth buffer, I could then change my depth test function to GL_LEQUAL and avoid a lot of unnecessary work for pass-2's fragment shader. Depth writes could also be disabled for this pass.

So... is there some way to do one of the following?

• create my own framebuffer that uses the screen's depth buffer (but still writes colors to a texture)
• attach my own renderbuffer to the default framebuffer's depth attachment

The only workaround I can think of (and I haven't tried this yet, so I have no idea what kind of effect this will have on performance) is to have the second pass also render to a texture, and then have a third pass that just "blits" the texture to the screen.

Answer 1

From reading the OpenGL® ES Common Profile Specification Version 2.0.25 it appears that neither of these are possible.

Section 4.4.2 says:

Framebuffer-attachable images may be attached to, and detached from, application-created framebuffer objects. In contrast, the image attachments of the window-system-provided framebuffer may not be changed by OpenGL ES.

(emphasis mine) So the second option in the question is not possible.

Section 4.4.3 suggests that the first option isn't possible either...

A renderbuffer object cannot be created with the name zero. If renderbuffer is zero, then any previous binding to target is broken and the target binding is restored to the initial state.

In the initial state, the reserved name zero is bound to RENDERBUFFER. There is no renderbuffer object corresponding to the name zero, so client attempts to modify or query renderbuffer state for the target RENDERBUFFER while zero is bound will generate errors.

...though this is less explicit. It isn't clear if there's some other name that could be used to refer to the default framebuffer's renderbuffers, though it's hard to imagine what name would make more sense than 0 since it's used for the default elsewhere.