Is MSAA affected by drawing order?

Recommended Posts

I've read that in MSAA each pixel's final color is an interpolation of its current color and the triangles color, depending on how many samples the triangle is covering.

That means that when drawing the scene in different orders affects the "current color" I mentioned above. So if I draw the scene in different orders when using MSAA, will the final render image be affected by this?

Share this post


Link to post
Share on other sites
1 minute ago, Pilpel said:

I've read that in MSAA each pixel's final color is an interpolation of its current color and the triangles color, depending on how many samples the triangle is covering.

No, it stores N colours (e.g. 2xMSAA stores 2 colours) and the "resolve" stage at the end blends them together.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Pilpel said:

If it stores N times more colours, how is it different that SSAA?

For what I know, in SSAA that color is calculated per each pixel with the image being 4 times higher resolution if we talk about 4x SSAA and then downsampled to your actual resolution.

With MSAA you render the image at your monitor resolution (so you start with 4 time less calculation compared to above) and then for each pixel of that, the same calculated color is shared for each of the 4 sub-pixels based on visibility (using depth buffer, 4 times bigger) and coverage (is the subpixel inside or outside the polygon?), and then the 4 sub-pixels(my example is 4xMSAA) are averanged togeter to get the final color, and all this check and averange is apparently less expensive than actually calculating the real lighting for 4 pixels, since you do 1/4 of the heavy calculation only once compared to SSAA.

Take it as a grain of salt, I am begginner in this.

Edited by MarcusAseth

Share this post


Link to post
Share on other sites

I'm not sure if I get it. Does MSAA differ from SSAA in a way that the pixel shader is ran, most of the times, fewer times per pixel?

Quote

In the extreme case where each of the multi sample locations is covered by a different triangle, a different shading computation will be performed for each location and the results then combined to give the final pixel, and the result and computational expense are the same as in the equivalent supersampled image.

Memory usage (number of elements in the color buffer) seems to be the same for both MSAA and SSAA, no?

Share this post


Link to post
Share on other sites

MSAA doesn’t actually improve on supersampling in terms of rasterization complexity or memory usage. At first glance we might conclude that the only advantage of MSAA is that pixel shader costs are reduced. However this isn’t actually true, since it’s also possible to improve bandwidth usage. Recall that the pixel shader is only executed once per pixel with MSAA. As a result, the same value is often written to all N subsamples of an MSAA render target. GPU hardware is able to exploit this by sending the pixel shader value coupled with another value indicating which subsamples should be written, which acts as a form of lossless compression. With such a compression scheme the bandwidth required to fill an MSAA render target can be significantly less than it would be for the supersampling case.

Share this post


Link to post
Share on other sites

By default, MSAA runs the pixel shader per-pixel, not per-sample (so if a triangle covers 3 samples, the PS still only runs once).
SSAA runs the pixel shader for every sample.

MSAA allows non-grid aligned sample positions, e.g. 2xMSAA over a 2x2 pixel area gives 8 sample locations, that might might look like:

|o |o |
| o| o|
+--+--+
|o |o |
| o| o|

SSAA samples are grid-aligned (when implemented by simply increasing render-target resolution).

Both MSAA and SSAA have the same memory usage, however MSAA might require less actual memory bandwidth due to HW compression schemes as mentioned above.

Share this post


Link to post
Share on other sites

To add to what others have already said, with MSAA you have same guarantee that you have for the non-MSAA case: the sub-samples will be written to in draw order (and within a draw by triangle order). Generally you only get order-independent results when you're using depth writes and depth testing, since that will typically ensure that only the closest pixels/sub-samples end up being visible. So for instance if you're rendering transparents without depth writes, you'll get the same issues where you need to sort to ensure that you get correct results.

The only time this isn't the case is when using vendor-specific MSAA extensions (AMD's EQAA, and Nvidia's now-deprecated CSAA). These work by decoupling triangle coverage from depth and color storage, and the results will be somewhat order-dependent even with depth buffering. In practice though it's not a big deal, and these extensions aren't very popular to begin with (at least on PC).

Also, a quick shameless plug for an article that I wrote about MSAA: https://mynameismjp.wordpress.com/2012/10/24/msaa-overview/

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now