As far as I understand, if you are consistent between GBuffer unpacking+lighting (pixel center evaluation) and non-MS SRV-to-MS RTV (pixel center evaluation), you should get the same results as for forward MSAA?
As stated above by @MJP, the pixel center is used by default in MSAA. Or is the issue about not using the pixel center for MSAA in the first place (in forward MSAA as well) since it is not necessarily representative for the majority of subpixels?
Say you've got a purple triangle and a brown one:
Red X's are pixel centers, light-blue X's are 2xMSAA sample points.
After running non-MSAA deferred shading, we end up with this lighting buffer:
When you render your geometry a 2nd time, this time into the 2xMSAA buffer, the purple triangle will cover these sample locations (left) and the PS will run at these locations (right):
...but if it's fetching colours from that lighting buffer, the bottom right edge of the purple triangle will receive brown lighting.
And to solve it, you need to search the lighting buffer in the local neighbourhood for a texel that best matches the geometry (either best-fit or a bilateral filter), in which case you'll end up with those edge pixels realizing that the lighting buffer contains invalid data for them, and instead blending valid data that they find in their neigbourhood:
And this isn't fool-proof. If you've got sub-pixel geometry, then it's possible for this search to occasionally fail and find no valid data in the lighting buffer! So you should avoid sub-pixel geometry when using this technique.
7 hours ago, Hodgman said:And to solve it, you need to search the lighting buffer in the local neighbourhood for a texel that best matches the geometry (either best-fit or a bilateral filter), in which case you'll end up with those edge pixels realizing that the lighting buffer contains invalid data for them, and instead blending valid data that they find in their neigbourhood:
Does this assume operating at the subpixel level itself?
Could one use store additional ids for this in the GBuffer?
7 hours ago, Hodgman said:...but if it's fetching colours from that lighting buffer, the bottom right edge of the purple triangle will receive brown lighting.
Ah ok, I now see that forward MSAA does not suffer from this, since a fragment for both the purple and brown triangle would be evaluated and resolved with regard to the subpixels. When using the light buffer, the same two fragments are associated with the brown triangle's material. So in the naive approach, there is only one dominant "material" for all fragments of the same pixel independent of the actual material associated to the geometry.
Thanks for the visualizations! Really appreciated!
For what it's worth, both MotorStorm: Pacific Rift & Apocalypse (PS3) and Driveclub (PS4) used varying degress of Depth-only passes. Rift had lots of foliage and ground-rush (grass and the like) so we did a depth-only pass of just the world geometry after rendering upto 64 'occluders'. The occluders were just large polys, upto 8 verts I think, that were inside canyon walls, etc. These occluders were also used further up the pipe on the CPU side to do simple coarse-grained PVS. On Apocalypse, our VS were very heavy from lots of skinning and the like, so we ended up using conditional rendering. We did a full depth-only pass, and used the RSX feature that wrote out a pixel count for each draw call. On the full G-Buffer pass, the RSX used the value to decided whether to skip the draw-call. We did a large number of automated fly-throughs of our levels looking Fwd / Rev with this stuff on/off and it was a win, something like 1ms - 2ms if I recall. Everyone told us that Conditional Rendering was way slower, but not for us. On Driveclub, we again used Occluders but also a full depth-only pass. We fired off a ComputeShader right after to build tile info for lighting, etc which ran in parallel with our ShadowMap passes. Overally, this was a nice win despite some very heavy vertex shaders.
