I have a theoretical question. Why to use multisampling if it is possible, as an alternative, to double the size of the FBO (or triple or whatever) and just mix every 4 texels of the resulting texture into a single one writing it into the window’s default FBO? What is the benefit of using multisampled FBO comparing to that simple (as I see it) approach?
- Multisampled FBO = Res in pixels = WxH. multiple samples per pixel (e.g. 4)
- Double-size FBO = Res in pixels = 2Wx2H, 1 sample per pixel
Rendering to the former with multisample rasterization (MSAA) involves running the fragment shader for every one of the WxH pixels, and then downsampling that to WxH pixels, 1 sample per pixel.
Rendering to the latter involves running the fragment shader for every one of the 2Wx2H pixels, and then downsampling that to WxH pixels, 1 sample per pixel. This is effectively supersample rasterization (SSAA).
You see the difference. MSAA results in 1/4 of the fragment shader executions that SSAA does (or in general 1/num_samples). This can be a big win performance wise. The tradeoff is that with MSAA you only have the shading value (e.g. color) sampled/computed one per pixel and set on the applicable samples, whereas in SSAA you have it sampled/computed multiple times per pixel. Both give you nice antialiased geometry edges, but the latter may give you slightly better shading results if your fragment shader computations don’t antialias well.
You can also do supersample rasterization (SSAA) on a multisampled FBO. Just allocate a multisampled FBO and then enable per-sample shading (e.g. ARB_sample_shading). If you do this on an FBO that’s WxH pixels with 4 samples per pixel, then you have 4WH frag shader executions, the same as with your double-size FBO case.
Oh, thanks Dark Photon, silly me thought the FS is always executed independently for each of the sample in MS FBO receiving the input for slightly different pixel’s positions.