See Figure 7 on pg. 11 (acroread pg 13). Pass #1 renders the opaque geometry, Pass #2 uses the depth texture generated in pass #1 to fade the particles out near opaque geometry. With this processing path, no geometry batches have to pass down the rendering pipe twice.
Question is, is there a way in OpenGL that (in pass #1) the “Color buffer” and “Depth buffer” can be in the window-system FBO, while the “Fp32 (depth) texture” can be in a user-defined FBO?
The goal being to render the opaque objects into the scene (color/depth) and generate the depth texture from them all-in-one go, …without having to submit some batches multiple times.
Well, I didn’t read the entire paper, but if I remember correctly, in MRT the drawbuffer parameter list should come from either the window-system provided buffers (GL_FRONT,GL_BACK,…) or the FBO buffers (GL_COLOR_ATTACHMENT0,…) but not a mix of the two. And since you can’t use the window-system provided buffers as textures for the second pass (unless you copy the contents of course) you’re stuck with FBO. It’s easy enough to draw the FBO-texture as a fullscreen quad in the window-system provided buffers if you don’t want to submit the batches again.
Thanks, that’s what I thought, but wanted to make sure I wasn’t missing something obvious.
It’s easy enough to draw the FBO-texture as a fullscreen quad in the window-system provided buffers if you don’t want to submit the batches again.
May end up doing just that. The snag with it is our app must have MSAA. From the spec, I gather that “All of the framebuffer-attachable images attached to a framebuffer object must have the same number of SAMPLES”, which means you can’t write the depth texture you need for the particles directly, even if you’re using an FBO – you have to do a full depth buffer downsample to get the single-sample depth texture, in addition to a full color buffer downsample to blit it to the system FBO at the end. Doable, but seems like a big waste of GPU resources for something so simple.
Need to do some timings, but I’m beginning to think a single-sample depth-only pass to generate the depth texture up-front (via FBO) is gonna be cheaper than all this full-screen depth and color downsampling and blitting to get around the binding limitations…
The resolve operation is affected
by calling BlitFramebufferEXT (provided by the EXT_framebuffer_blit
extension) where the source is a multisample application-created
framebuffer object and the destination is a single-sample
framebuffer object (either application-created or window-system