多重采样抗锯齿（MultiSampling Anti-Aliasing，簡稱MSAA）是一种特殊的超级采样抗锯齿（SSAA）。MSAA首先来自于OpenGL。具体是MSAA只对Z缓存（Z-Buffer）和模板缓存（Stencil Buffer）中的数据进行超级采样抗锯齿的处理。可以简单理解为只对多边形的边缘进行抗锯齿处理。这样的话，相比SSAA对画面中所有数据进行处理，MSAA对资源的消耗需求大幅減少，不过在画质上可能稍有不如SSAA。
http://www.cnblogs.com/mikewolf2002/archive/2012/11/24/2785441.html
http://en.wikipedia.org/wiki/Alpha_to_coverage
EQAA
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch04.html
to be continued....
Alpha_to_coverage
This technique uses the alpha channel of textures as a coverage mask for anti-aliasing.
Alpha to coverage multisampling is based on regular multisampling, except that the alpha coverage mask is ANDed with the multisample mask. Alpha-to-coverage converts the alpha component output from the pixel shader to a coverage mask. When the multisampling is applied each output fragment gets a transparency of 0 or 1 depending on alpha coverage and the multisamplingresult.
alphatocoverage 采样技术是基于常规的采样技术，除了alpha coverage mask是和采样mask进行与（and）运算。atc把alpha分量从ps输出到coverage mask。多重采样依据这个alpha coverage 与 多重采样的结果
alpha 被当做mask 管线中会根据alpha的mask来采样
这样明显无法同时实现一个透明功能和 mask功能
Unlike alpha blending, alpha to coverage is order independent, so leaves and fronds do not need to be sorted by depth to achieve a correct image.
Alpha-To-Coverage
Alpha-to-coverage is a multisampling technique that is most useful for situations such as dense foliage where there are several overlapping polygons that use alpha transparency to define edges within the surface.
You can use the AlphaToCoverageEnable member of D3D11_BLEND_DESC1 or D3D11_BLEND_DESC to toggle whether the runtime converts the .a component (alpha) of output register SV_Target0 from the pixel shader to an n-step coverage mask (given an n-sample RenderTarget). The runtime performs an AND operation of this mask with the typical sample coverage for the pixel in the primitive (in addition to the sample mask) to determine which samples to update in all the active RenderTargets.
If the pixel shader outputs SV_Coverage, the runtime disables alpha-to-coverage.
Note In multisampling, the runtime shares only one coverage for all RenderTargets. The fact that the runtime reads and converts .a from output SV_Target0 to coverage when AlphaToCoverageEnable is TRUE does not change the .a value that goes to the blender at RenderTarget 0 (if a RenderTarget happens to be set there). In general, if you enable alpha-to-coverage, you don't affect how all color outputs from pixel shaders interact with RenderTargets through the output-merger stage except that the runtime performs an AND operation of the coverage mask with the alpha-to-coverage mask. Alpha-to-coverage works independently to whether the runtime can blend RenderTarget or whether you use blending onRenderTarget.
Graphics hardware doesn't precisely specify exactly how it converts pixel shader SV_Target0.a (alpha) to a coverage mask, except that alpha of 0 (or less) must map to no coverage and alpha of 1 (or greater) must map to full coverage (before the runtime performs an AND operation with actual primitive coverage). As alpha goes from 0 to 1, the resulting coverage should generally increase monotonically. However, hardware might perform area dithering to provide some better quantization of alpha values at the cost of spatial resolution and noise. An alpha value of NaN (Not a Number) results in a no coverage (zero) mask.
Alpha-to-coverage is also traditionally used for screen-door transparency or defining detailed silhouettes for otherwise opaque sprites.
alphatocoverage 和alpha blend是独立的
http://msdn.microsoft.com/ZH-CN/library/windows/desktop/bb205072(v=vs.85).aspx#Alpha_To_Coverage
---------------------------
ccording to the OpenGL GL_ARB_multisample specification
http://en.wikipedia.org/wiki/Multisample_anti-aliasing
--------------------------------------
gl 实现 msaa --FBO
http://blog.csdn.net/xiajun07061225/article/details/7690805
--------------------
http://www.cnblogs.com/mikewolf2002/archive/2012/11/24/2785441.html
coverage aa
http://www.cnblogs.com/mikewolf2002/archive/2012/11/22/2783235.html
http://www.cnblogs.com/gongminmin/archive/2011/05/16/2047506.html
如图1的情况，没有centric插值的话，蓝色三角形的两个采样点将都得到纯蓝的颜色（外差而得），最终像素的颜色就是(2 * (0, 0, 1) + 14 * (1, 1, 0)) / 16 = (0.875, 0.875, 0.125)。有centric插值的话就是个更正确的浅蓝色((1, 1, 1) + (0.77, 0.77, 1)) / 2 = (0.885, 0.885, 1)，最终像素颜色是(2 * (0.885, 0.885, 1) + 14 * (1, 1, 0)) / 16= (0.98, 0.98, 0.125)。如下图所示：
性能统计：每个像素里PS执行次数为每个覆盖到该像素的三角形一次，占用空间N个color + N个depth。
---
这段看了很多遍才懂，结合mike
有centric的情况下
蓝色三角形在这个pix算一次 ps ((1, 1, 1) + (0.77, 0.77, 1)) / 2 = (0.885, 0.885, 1)
黄色三角形在这pix算一次ps (1, 1, 0)
两者加权平均