paper:http://developer.amd.com/gpu_assets/Resolve%20your%20Resolves.pdf

I can say some code in dx demo,
if ( g_bPostProcessON && pBackBufferDesc->SampleDesc.Count > 1 )
{
D3D11_TEXTURE2D_DESC Desc;
g_pTexRender11->GetDesc( &Desc );
pd3dImmediateContext->ResolveSubresource( g_pTexRender11, D3D11CalcSubresource( 0, 0, 1 ), g_pTexRenderMS11,
D3D11CalcSubresource( 0, 0, 1 ), Desc.Format );
ID3D11RenderTargetView* aRTViews[ 1 ] = { NULL };
pd3dImmediateContext->OMSetRenderTargets( 1, aRTViews, pOrigDSV );
}
why do we need resolve the msaa target to non-msaa target?
Can't we use mass rendertarget directly?
that code is copy from HDRToneMapping demo in directx sdk.
and then i find a paper: http://developer.amd.com/gpu_assets/Resolve%20your%20Resolves.pdf
it said:

Useful Resolves
We know that the use of MSAA render targets is only helpful when draw calls produce visible “jaggies”. In an ideal world the main geometry pass would be rendered in MSAA mode, and then resolved to a non-MSAA render target. Any subsequent post processing passes would all be completed in non-MSAA mode. This would therefore give rise to just a single resolve per frame. However there are two reasons why a post processing technique may need to be performed in MSAA mode:
1) If a post processing technique enables subsample based depth testing, it can result in an update to some of the subsamples of a pixel.
2) In a similar way if alpha blending is enabled, then subsample data is preserved through the blend operation.[/quote]
so, I want to understand if this is a must.

Microsoft decided when making the DirectX API that you should be able to choose when to resolve your MSAA render target. If you want to resolve it at the end, the beginning, or the end you can do that. The chose to make the resolve explicit, so you have to call ResolveSubresource when you want to resolve it. If you want to resolve to the monitor then you must do the resolve as the last operation and you must resolve it to the back buffer. Remember the back buffer is what is sent to the monitor, and the monitor has no understanding of MSAA. Only your graphics card has an understanding of MSAA.

Do you fully understand MSAA? If you don't somebody might be able to better explain it. I tried finding a good article, but I had a hell of a time finding one.

You can do a manual resolve if you want using a pixel shader. However certain special MSAA modes (like Nvidia's CSAA) will make use of information that you can't access, so the only way to use them properly is with ResolveSubresource.

Microsoft decided when making the DirectX API that you should be able to choose when to resolve your MSAA render target. If you want to resolve it at the end, the beginning, or the end you can do that. The chose to make the resolve explicit, so you have to call ResolveSubresource when you want to resolve it. If you want to resolve to the monitor then you must do the resolve as the last operation and you must resolve it to the back buffer. Remember the back buffer is what is sent to the monitor, and the monitor has no understanding of MSAA. Only your graphics card has an understanding of MSAA.

Do you fully understand MSAA? If you don't somebody might be able to better explain it. I tried finding a good article, but I had a hell of a time finding one.

Thank you for your answer
~if we can use a msaa rendertarget as a shader resource view directly?
in other words, if i use msaa rendertarget as a shader resource view directly, do it cause any problems? Efficiency issues?
if not why some demos in nvidia sdk or directx sdk will reslove msaatarget?

Yes you can access the shader resource view of an MSAA render target in the shader directly.
Here is a simple example:
#define SAMPLES 16
Texture2DMS< float3, SAMPLES > gTexture;
float4 main( uint2 pos )
{
float3 color = 0.0f;
for( uint sample = 0; sample < SAMPLES; ++sample )
{
color += gTexture.Load( pos, sample );
}
color /= float( SAMPLES);
return float4( color, 1.0f );
}




Note: this example is just off the top of my head, so there are probably some errors.