@Hodgman: Hmm.. don't you think that will lower the performance?
Yes, quite possibly. But your current version doesn't even work, so I'd value bad performance higher than no performance
However, in some cases, this may actually increase performance. Drawing the scene twice, where the first time you only draw depth, and the second time you use your real pixel shaders, is known as a "z pre pass", "depth pre pass", "zpp", etc.
Doom 3 chose to do this on purpose, because it lets the GPU take full advantage of the depth buffer, to avoid overdraw.
Say you've got a camera looking through 3 walls:
Cam -> |A| |B| |C|
If you draw C, then B, then A, then you're running 3 different pixel shaders, even though only the last one (A) counts -- it overwrites the previous results. That's "overdraw".
By drawing the whole scene's depth buffer first, then in the second pass, B & C will be skipped, because they fail the depth test.
In scenes that have a lot of overdraw, then a ZPP may actually improve performance.
What modern games do?
Use DX11 where you can use MSAA textures and MRT at the same time
Another solution though would be to use a post-process anti-aliasing solution, like FXAA instead of MSAA, as mentioned above.
Wasn't the problem with DirectX 9 that while you could create all your targets with some MSAA technique, because of the way you did lighting and accumulated all the targets with the lighting the results were not correct? And DirectX 10.1 gave you access to all the samples in a multisampled target and also gave you access to the depth buffer in a similar manner?
Yes, D3D9 gives no way to access the sub-samples (besides averaging them all together in a standard resolve step), so even if you do manage to render out an MSAA G-buffer, you can't make use of it.
Would this look correct? Rendering the albedo, normal and specular targets all separately, with MSAA on and....
Nope. Medo3337 isn't rendering a G-buffer. He's just using forward rendering, but also outputting depth to a colour texture.
The averaging of depth will also be wrong, but probably still close enough to correct for most purposes.
Edited by Hodgman, 07 September 2013 - 09:25 PM.