Antialiasing Quality - Grids and Driver

When we talked about the ROP and display pipe here, we let you know that the ROP could sample from all supported rendertarget formats when multisampling including floating point pixel representations (although that 'all' is not quite correct, which we'll show you soon), and that the display pipe in NVIO was man enough to take any of those formats for scanout or digital display, at up to 10 bits per colour channel no less.

In terms of antialiasing quality, the hardware can perform true 8x multisampling in hardware at a rate of 4 samples per cycle (with the first effectively for free), looping through the ROP again for the second sample set. Sample locations are laid out on a 4-bit grid (16x16 maximum EER), and all multisample modes obtain optimal pixel coverage via rotated grids.

The hardware also supports what's called coverage sampling. Combined with multisampling, CSAA will take extra binary coverage samples in the subpixel, to determine if triangles intersect the subpixels at those sample points. If they do, data at the sample locations is used to influence the sample resolve and thus the final framebuffer blend for that tested pixel.

Should coverage sampling fail for the pixel, the hardware will drop back to the nearest multisample mode, depending on what the user has asked for via the driver control panel. Coverage sampling as implemented by NVIDIA in G80 is outside of any major API and thus applications have no control over its quality or usage, negating its impact for users unaware the feature even exists.

We start with the sample positions for each mode as presented in the control panel when you're overriding the application. Grids are generated from our own in-house sample locator and output tools, and you can find the output from R580 and G70 as a comparison in Appendix A.

Per pixel, you can see each sample location for each of the six main modes. 8x via the D3D API uses the displayed 8xQ grid (so there's 8 true multisamples). 8x, 16x and 16xQ are revealed as the mixed modes, with the blue sub-pixel points representing the coverage samples the hardware takes.

Fallback sample locations therefore show that 16x is 4xRGMS + 12xCS, 16xQ is 8xSSMS (sparse sampled) + 8xCS, and 8x is 4xRGMS + 4xCS, with performance scaling as a function of the multisample cost most of all. The hardware still supports user-selectable transparency AA modes for alpha textures, as the older generation architecture did, and both multisample- and supersample-based modes are still there for that.

Coverage sampling fallback happens on a per-pixel basis depending on the coverage testing, however given the guaranteed fallback of at least 4x multisampling whatever the CSAA mode, rather than no AA at all, the potential image quality reduction should be mostly invisible to the viewer.

Application-controlled is the standard mode, where the application requests AA via its chosen API. Off is, well, off. Enhance the application setting works in conjunction with the application and its request for AA, so that the driver can see how it performs its regular AA to see if CSAA can be further applied in conjunction. You set a chosen CSAA mode in the driver and turn on AA in your app too for that setting to work. It's not too clear why the non-CSAA modes are still available as choices with Enhance the application setting, though.

Override any application setting is the forced mode, where the application gets your chosen AA mode regardless of what level of quality it wants via the API, or whether it even supports AA at all. Image quality comes at your own risk in that case. We look at image quality using a test application and a game title next.