RTT, FBOs and Multisampling

[Aeluned]

I'm sure this has been discussed but I can't seem to find it so, sorry.

Prior to 3.2 the way to render to texture using an FBO with multisampling would be render to a multisampled render buffer then blit that buffer to another FBO with a texture attached.

I'm thinking about using multisampled textures instead now but I have a question from a preformance point of view.

It seems that I need to average the samples myself in a shader. Am I really better off doing 4-16 texel fetches per fragment? In my mind it seems a blit would be faster.
Sure, I could just implement it and run some timings but hoping someone could save me some time and address this if they know.


Thanks.

[kyle_]

I wouldn't count on blit being faster here - it most probably does the same thing internally. Why do you think a blit could be faster?
It may be simpler in your code though, so unless you need to do custom resolve you should just blit.

[Aeluned]

I wouldn't count on blit being faster here - it most probably does the same thing internally. Why do you think a blit could be faster?

Because I mistakenly believed that a blit was a simple memcpy. After some digging, I realized it isn't. I did end up just doing the timings and got nearly identical results both ways (which supports your theory)

It may be simpler in your code though, so unless you need to do custom resolve you should just blit.

I dunno, I actually feel like the multisampled texture is the cleaner approach. Anyway, mystery solved I suppose. Thanks for the reply.

[Aeluned]

One more thing. Wouldn't there be less memory overhead in using multisampled textures? In order to blit, I need a multisampled render buffer (which I draw to) and an additional texture allocation for the sister FBO that I blit to. If I use multiple color attachments (which I do) I need additional textures for all those as well.

From what I understand nVidia's coverage sampling extension reduced the memory overhead involved in multisampled render/depth/stencil buffers but these don't seem to be compatible with multisampled textures. (I get a framebuffer incomplete multisample when attempting to use a multisampled texture color attachment with coverage sampled depth buffers.

[Dark Photon]

One more thing. Wouldn't there be less memory overhead in using multisampled textures? In order to blit, I need a multisampled render buffer (which I draw to) and an additional texture allocation for the sister FBO that I blit to. If I use multiple color attachments (which I do) I need additional textures for all those as well.

From what I understand nVidia's coverage sampling extension reduced the memory overhead involved in multisampled render/depth/stencil buffers but these don't seem to be compatible with multisampled textures. (I get a framebuffer incomplete multisample when attempting to use a multisampled texture color attachment with coverage sampled depth buffers.

Couple thoughts.
- Don't bet on your downsample being faster than the vendors.
- Use textures if you need to feed that texture data back into the pipeline. Use renderbuffers otherwise.
- If you can avoid the need for the downsample, render to multisample texture and just feed that textre back into the pipeline (into a shader directly).
- If you need single sample into the subsequent pass via a fast downsample, render to multisample renderbuffer and then blit to single sample texture. Feed the single sample texture back in.
- AFAIK, the mem consumption for the FBO is trivial. The mem consumption of the attachments/render targets is the big fish (textures or renderbuffers)
- MSAA textures of course consume more than single sample. Don't think there's an appreciable difference in consumption between MSAA textures and MSAA renderbuffers though. Not sure exactly what your "less memory overhead" question was asking about.
- Re CSAA, did you check out NV_framebuffer_multisample_coverage?

[Aeluned]

Couple thoughts.
- AFAIK, the mem consumption for the FBO is trivial. The mem consumption of the attachments/render targets is the big fish (textures or renderbuffers)
- MSAA textures of course consume more than single sample. Don't think there's an appreciable difference in consumption between MSAA textures and MSAA renderbuffers though. Not sure exactly what your "less memory overhead" question was asking about.

Right, meaning that if I want to render to texture with multisampling support the 'blit' route would require more memory than using the multisampled texture approach (since I need to allocate a multisampled renderbuffer and then (and this is where the extra memory requirement comes in) a texture2D of the same resolution bound to the color attachment of another FBO which I would be blitting to.

- Re CSAA, did you check out NV_framebuffer_multisample_coverage?

Yeah, I've been using that as long as I don't also need to attach a depth texture or render to multisampled texture. Because CSAA is not compatible with multisampled textures which nets me a GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE if I attempt it. There's no glTexImage2DMultisampleCoverage.

Your points are duly noted, thanks.