Jump to content
  • Advertisement
Sign in to follow this  
Quat

DX11 Copying MSAA depth buffer dx11

This topic is 2653 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am using DX11.

I am using the light prepass system, where I first render the view space normals and depth to a render target. This pass also lays down the scene depth, so there is no overdraw in later passes.

Now for MSAA, I was going to use non-msaa render targets and depth buffers for generating the g-buffer and screen space light map, and just use MSAA for the final pass. However, with this I need two depth buffers--one multisampled for the back buffer, and one not multisampled for the g-buffer. So my question is if there is a way to avoid drawing the scene depth twice.

I don't think I can use MSAA g-buffer because that would average depths at the edges.

Is it possible to have two render targets where one is multisampled and the other is not? I am thinking of having something like (g-buffer and non-multisampled depth buffer) and (null render target with multisampled depth buffer).

Share this post


Link to post
Share on other sites
Advertisement
Not using MSAA for the G-Buffer pass will give you really bad artifacts. You will end up having lighting information for a completely different triangle applied to subsamples for edge triangles during your second geometry pass. Or if no triangle was rendered at all to a pixel during the G-Buffer pass and a subsample samples lighting from that texel, it will get black because there will be no lighting there at all.\

If you really want to avoid artifacts, you have to do it like this:

1. Render G-Buffer with MSAA
2. Render lighting with MSAA, making sure you individually light subsamples for triangle edges
3. Render your second geometry pass, making sure to sample the right subsample from the lighting buffer for edge triangles

It sucks pretty badly from an implementation and performance point of view, and it's one of the big reasons that I really don't like light prepass.

Anyway to answer your question...all render targets and depth stencil buffers need to have the same MSAA mode when you're rendering. You can't have one of them with MSAA, and one of them without. You can render a depth buffer with MSAA and manually resolve it using a pixel shader if you want.

Share this post


Link to post
Share on other sites
OK, I read the ShaderX7 article on Deferred Shading and MSAA and I see what you mean.

I would like to confirm some things:

1. If I create a MSAA back buffer and depth buffer, I must enable D3D11_RASTERIZER_DESC::MultisampleEnable so that the system will automatically resolve the back buffer before presenting. I need to test this again, but I seem to recall getting antialiasing even if I didn't enable this state, as long as I created a MSAA back buffer and depth buffer.

2. MSAA textures are never resolved automatically (you must call ResolveSubresource). To sample a MSAA texture at the sample level, you must use Load(texCoord, sampleIndex).

3. For a pixel shader to run at sample frequency, you must have input SV_SAMPLEINDEX.

4. Use SV_Coverage to detect edges, so that we only run the pixel shader per sample about the edge.


Also, what do you like instead of light prepass? Just full deferred renderer?

Share this post


Link to post
Share on other sites
1. The setting in the rasterizer state doesn't have anything to do with resolving the render target. It actually controls how MSAA is handled during rasterization. The documentation that explains it is here and here, although it can be a bit confusing if you're not familiar with how MSAA works. Basically what happens when you disable that is that you have multiple subsamples in your render target, but the rendering will occur as if it were a non-multisampled render target.

2. Yes, these are both correct. You must also declare your texture as a Texture2DMS to be able to load subsamples (you will get a warning from the debug layer if you don't, or if you try to use a Texture2DMS with a non-multisampled texture).

3. Yes, you must declare it and use it in your shader program. Alternatively, you can also use the "sample" modifier on one of your pixel shader inputs to get the shader to run per-sample. This modifier causes the input to he interpolated to each MSAA sample point, rather than the pixel center.

4. SV_Coverage is a great way to detect edge pixels. You can also use it as an output, to control which subsamples get written by the pixel shader.

I prefer a full deferred renderer. IMO light prepass is only really worth it on platforms where multiple render targets aren't available, or are too expensive.


OK, I read the ShaderX7 article on Deferred Shading and MSAA and I see what you mean.

I would like to confirm some things:

1. If I create a MSAA back buffer and depth buffer, I must enable D3D11_RASTERIZER_DESC::MultisampleEnable so that the system will automatically resolve the back buffer before presenting. I need to test this again, but I seem to recall getting antialiasing even if I didn't enable this state, as long as I created a MSAA back buffer and depth buffer.

2. MSAA textures are never resolved automatically (you must call ResolveSubresource). To sample a MSAA texture at the sample level, you must use Load(texCoord, sampleIndex).

3. For a pixel shader to run at sample frequency, you must have input SV_SAMPLEINDEX.

4. Use SV_Coverage to detect edges, so that we only run the pixel shader per sample about the edge.


Also, what do you like instead of light prepass? Just full deferred renderer?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!