Assuming it is not needed anymore for deferred and assuming you could afford it, I start to wonder if this idea of mine makes sense:

1. GBuffer packing (opaque_models): write to multiple non-MS RTVs (GBuffer)
2. GBuffer unpacking (opaque_models): write to one non-MS RTV (Color Buffer)
3. Forward (opaque_models): fetch color from the Color Buffer and write to one MS RTV (back buffer)
4. Remaining forward passes for emissive and transparent models and sprites

The vertex shader price of step 3 is equal to an early z-pass. What remains is a texture load/fragment which enables MSAA and alpha-to-coverage in a deferred shading algorithm.

12 hours ago, MJP said:

For a Z prepass to work correctly, the part of your VS that computes the position needs to exactly match between your Z-only pass and your main pass.

Solved the problem. Thanks

10 hours ago, Infinisearch said:

Instead of a full z-only pass why not just do one with the major occluders for a given view?

Yeah, I've worked on games where three specific objects were included in a depth-pre-pass (prior to the G-buffer pass), and that's it! They happened to always be very close to the camera and occluded a lot of pixels, and also had high depth complexity / overlapping parts. It turned out that a generic ZPP was a loss, but doing ZPP for just these three specific objects was a win

There's no generic general purpose realtime renderer that's a good fit for every game. Every single console game that I've worked on has used a different rendering pipeline. Do what works in your situation.

11 hours ago, matt77hias said:

Assuming it is not needed anymore for deferred and assuming you could afford it, I start to wonder if this idea of mine makes sense:

1. GBuffer packing (opaque_models): write to multiple non-MS RTVs (GBuffer)
2. GBuffer unpacking (opaque_models): write to one non-MS RTV (Color Buffer)
3. Forward (opaque_models): fetch color from the Color Buffer and write to one MS RTV (back buffer)
4. Remaining forward passes for emissive and transparent models and sprites

The vertex shader price of step 3 is equal to an early z-pass. What remains is a texture load/fragment which enables MSAA and alpha-to-coverage in a deferred shading algorithm.

Any thoughts on this?

When do you do lighting?

34 minutes ago, Infinisearch said:

When do you do lighting?

At the unpacking (step 2). It is basically deferred shading, but instead you use the image as an srv in a forward step (which unfortunately has a cleared MS dsv to start with). So you will have all the MSAA/Coverage/Depth fluff while having a very cheap PS which just fetches the color: double deferred

I don't know if I am missing something, but having MSAA and alpha-to-coverage without requiring edge fixing, post AA, seems nice.

That's basically how Light Pre-Pass (aka deferred lighting) worked, and how it supports MSAA.

There's some tricky pitfalls though. Your GBuffer sample locations are at pixel centers, but your later MSAA sample locations are not... So you can't simply sample the deferred lighting results in pass 3, or you might fetch data from a completely different triangle/object. Instead, you have to search the local neighbourhood (e.g. 3x3 pixels) and find which GBuffer pixel is the best normal/depth match, and then fetch the lighting result for that pixel.

See also Inferred Lighting, which implements this search algorithm with bilateral filtering.

MSAA evaluates only one PS per pixel. Which SV_Position is used for this PS if the center pixel isn't used? The centroid of the subpixel range?

The pixel center is used interpolating all vertex attributes (including the position) unless you use the "centroid" or "sample" interpolation modifier. "centroid" causes the attributes to be interpolated to the centroid of covered sub-samples, while "sample" causes it to be evaluated at the center of the subsample being shaded (using "sample" will cause your pixel shaders to run at sample-rate!). With the default "pixel center" behavior your attributes may be extrapolated off the triangle's surface at edge pixels, so you have to watch out for that.

There's also the EvaluateAttributeAtSample, EvaluateAttributeAtCentroid, and EvaluateAttributeSnapped intrinsics that you can use.

6 hours ago, MJP said:

The pixel center is used interpolating all vertex attributes (including the position) unless you use the "centroid" or "sample" interpolation modifier. "centroid" causes the attributes to be interpolated to the centroid of covered sub-samples, while "sample" causes it to be evaluated at the center of the subsample being shaded (using "sample" will cause your pixel shaders to run at sample-rate!). With the default "pixel center" behavior your attributes may be extrapolated off the triangle's surface at edge pixels, so you have to watch out for that.

There's also the EvaluateAttributeAtSample, EvaluateAttributeAtCentroid, and EvaluateAttributeSnapped intrinsics that you can use.

Thanks, really interesting stuff.