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.

[Dark Photon]

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.

Ah! Gotcha. Guess you could blit CSAA texture to a genuine MSAA texture (if that's supported), but that would kind of defeat the advantage in the case that you're feeding the MSAA texture back into the pipe. IIRC the whole point of CSAA is saving memory and that defeats the purpose. AFAIK with MSAA bandwidth compression, you don't send 8 samples to the memory for 8xAA in the interior of polygons but just 1 so no real advantage there between CSAA/MSAA.

However, in the case where you are doing the render to CSAA texture and doing a Blit to downsample to single sample texture for feeding back into the pipe, then seems it could potentially save you a lot of memory.

[kyle_]

Just a minor point on multisampled textures vs renderbuffers. If you dont care about pre 3.2 GL versions, I'd just forget about renderbuffers if it simplifies anything for you - there is absolutely no advantage over textures.

[Aeluned]

Just a minor point on multisampled textures vs renderbuffers. If you dont care about pre 3.2 GL versions, I'd just forget about renderbuffers if it simplifies anything for you - there is absolutely no advantage over textures.

It is my understanding that nVidia's CSAA offers some memory savings over MSAA (over both renderbuffers and textures). I don't know if this information is out of date (or wrong), but if true, this is the sole reason I would still use renderbuffers if I didn't need to feed the render back into the pipe. In this case, I can use CSAA instead of MSAA which would have less of an impact on memory over using multisampled textures.

[kyle_]

I was referring to baseline spec only. Of course, do use any extensions that make sense for you.
If you limit yourself to NV only, have a look at: http://www.opengl.org/registry/specs...ultisample.txt