AMD's programmable filters, thinking about improvements

It's worth remembering that the filters AMD employ with their CFAA implementation aren't fixed. Their programmable nature is such that a different filter is an easy thing for AMD's driver engineers to switch to, possibly weighting less the contribution from multisamples outside the target pixel and thus improving subjective image quality compared to their current linear tent filter.

AMD Edge Detect

Edge detect when applied to CFAA is such that if all the colour compression of the multisamples for the target pixel is at maximum, indicating all the samples have the same colour and thus there's no edge, the tent filter isn't computed (in fact there's no filter run for the target pixel).  If an edge is detected, the standard chosen filter is run.  That can mean a lower per-pixel computation cost and thus potentially higher performance.

Thinking about improving on the tent and box down-filters

Remember that for a box filter, each sample gets equal weighting regardless of the distance to the pixel centroid.  In the example to the left, it doesn't matter that the length of the line x is longer than the length of the line y, and thus the sample lies further from the centroid--it still gets an equal weight.

If the aim of the game is to move closer to the pre-filter ideal, the best way to improve any filter choice first of all is to provide it with more samples. More subpixel samples better approximates area coverage contribution for the target pixel, because more samples means more chance of sampling from smaller contributing geometries, and it means more coverage of the pixel area in general.

Limiting the tent filter to sampling inside the pixel boundary could be one improvement, increasing the weight of sample contribution to those nearer the centroid than the current filter, which looks outside the pixel boundary.

It's the blurring property of the linear contribution (because it's not an impulse filter) in the tent filter that causes a decrease in subjective image quality, and if you concede that you can't take more subpixel taps in the hardware the only way to adjust image quality is to adjust the filter.

This is where it gets hard to suggest an alternative to box or tent, though. In this situation with a limited number of filter inputs and only so many cycles you want to devote calculating your filter, and with little help with choosing a different filter per-pixel depending on certain attributes (something we'll come back to), it's hard to choose a down-filter that's better than tent and that isn't box.

You might want to start with a small Gaussian kernel and modify values via trial and error, or do multi-pass with two or more different kernels. Who knows, since the down-filter calculation limits are fairly hard in this situation for real time graphics acceleration and acceptable image quality.

In practice, using a small software test harness (with limited subpixel precision, limited to RGB colour space with INT8 final pixels) to check out and play with different down-filters, it was hard to improve on AMD's current tent filters and remove the blurring property, while still generating a final pixel colour that was close to correct, with a filter that's not too computationally expensive.

Things become more complicated if your pixel colour can lie in a different colour space and have more than 8 integer bits per channel, and those have to be taken in to account when making a user-selectable control panel filter for MSAA. You could reasonably argue that AMD should have left it in the hands of the application developer given the way DirectX is evolving, and it's that which we'll talk about now.