Multisampling Anti-Aliasing: A Closeup View

May 22, 2003 / by aths / page 5 of 8 / translated by 3DCenter Translation Team

   Framebuffer compression: low hanging fruit

What's marketed as a compression with R300 and Geforce FX by ATi resp. nVidia, actually isn't one. Because only bandwith is saved, and not a bit of RAM. Framebuffer compression is very likely to be a lot simpler than Z-compression. With multisampling all subpixels in a pixel have the same colour (at least as long as the entire pixels lies within the polygon). This is taken advantage of and hence, in this case, Radeon models starting from the 9500 and GeForce FX models starting from 5600 write the colour into the framebuffer only once, along with a note that it applies to all subpixels. But if in the process of rendering the pixel is covered by a visible edge, the colour samples are written into the framebuffers the usual way.

How exactly the framebuffer compression is implemented remains unknown. Basically there are two approaches that are realistic. The first one is that a note is attached to each pixel which is entirely in the polygon, saying "the colour of multisampling buffer 0 applies to all subpixels". The second possible way is that a tile (or burstline) based architecture is used. With render-to-texture no compression seems to take place at all. As far as we know, colour compression in both ATi and nVidia chips is only active in conjunction with multisampling, and compresses by up to the level selected for anti-aliasing (ie. up to 4:1 compression for 4x AA).

As shown before, there is a significant increase in frame rate, when Z compression is enabled. A colour compression is the next logical step and delivers a further performance boost, especially in modes like 4x and higher. ATi market this feature as part of the HyperZ III package, where they lump together various methods to increase efficiency, while nVidia adds it to the image quality enhancing package "Intellisample". How much further Intellisample HCT (which was introduced with NV35) boosts the speed, is still unknown. The FX 5200 is capable of multisampling anti-aliasing, but not of colour compression.

Framebuffer compression is absolutely essential to fully make use of the multisampling potential. Without any loss of quality the speed is increased, especially when there's a lot of subpixels, a case where every bit of extra performance is very welcome anyway. Cards without this kind of colour pseudo-compression only realise half of multisampling's potential.

Multisampling alone only saves fillrate but thanks to these additional bandwith savings, anti-aliasing gains a lot of speed. So what's the flipside of the coin?

   Textures, pixelshaders and multisampling: Where there's light, there must be shadows

The pipeline samples one texture value, and writes it into the corresponding frame buffers for all four subpixels. Downfiltering reads out all the buffers and mixes the colours. Obviously nothing changes if you mix four identical colours. Hence textures are left alone by multisampling.

The entire pixel belongs to the triangle. The same color is
written into the multisampling buffers 4 times and these
4 equal colors are mixed during downfiltering.
Result: the pixel is exactly as if there wasn't any anti-aliasing.

Still the Z test is taken per subpixel, which is absolutely necessary. Let's pretend two triangles intersect. To be able to smooth the new edge at the intersection, the test has to be done for each subpixel. If this isn't done there is no smoothing, as can be seen on Parhelia. Parhelia's anti-aliasing only works on first class polygon edges and not on intersection edges.

But what happens to the textures on polygon edges when multisampling? We remember - for every triangle one colour per pixel is sampled, and then applied to all subpixels that belong to the polygon. Thus the subpixels don't get their actual colour value. This resulting effect appears especially around edges, where it's possible, that a texture value is sampled which isn't in the polygon. In DirectX 9 there is a means to avoid this, but only for pixel shader version 3.0 or higher. With a flag ("centroid") the sample position is adjusted to always fall into the polygon. Current cards have to cope with the fact that pixel colours for polygon edges may possibly be sampled in areas that aren't coverd by the polygon.

With pixel shader version 1.3 or higher (supported since GeForce4 Ti, Radeon 8500 and Parhelia), the colour value and the Z value can be altered in the shader. This is required to render Z correct bump mapping. Bump mapping creates roughness on a flat polygon by per-pixel lighting effects. This "bumpiness" is only illusion, the polygon remains flat. This illusion breaks when such a bumpy polygon intersects another one. To calculate what occludes what, according to the simulated bumps, the pixelshader, which is responsible for bump mapping, also has to alter the Z value, since this value is used for the "occlusion" check.

But afterwards the changed Z value applies to all the subpixels. In summary: it's now possible to get per-pixel correct occlusion out of the bumps, but it's not subpixel accurate.

There are some other multisampling approaches with their own peculiarities. Let's talk about these next.