Hi all, I've taken some time to research FSAA methods in general, and supersampling in particular. Spoiler: my conclusion is that we should implement 2x2 supersampling in the initial release of the FPGA prototype, and follow up later with rotated grid supersampling, and still later with a multisampling implementation.
Supersampling is by far the easiest form of FSAA to implement. We just render at twice the vertical and horizontal resolution and average together four pixels at a time during video scanout. The only hardware change needed is the averaging, which is easy and doesn't use any multiplies. There is a further minor cost at the driver level. Each pixel of any 2D blit to the frame buffer has to be replicated four times so that it averages down to the correct 2D image. Let's have a look at what kind of quality we can expect. This page illustrates the effect pretty well: http://www.beyond3d.com/articles/wildcatiii/index.php?page=page4.inc Simple 2x2 supersampling only generates a single intermediate color value between two contrasting polygons, which is quite obvious along the edges of the Kyro II example. The Geforce 4 example uses 4X multisampling (evidently a crude implementation) and only manages a single intermediate color as well. The Wildcat example achieves a glorious 16 distinct blending values. But we have no hope of achieving anything like that quality this time round on our hardware budget and schedule. (Note that they've carefully angled their example to get one color step per pixel, which makes it look even better than it would with some other slope.) To understand why 2x2 supersampling gives a single intermediate color, think about a vertical edge: it can cover no columns of the box, one column, or two columns. The one column case generates the intermediate color. As you can see, a single intermediate color does not look that great, especially when stressed with high contrast polygons. Games tend to be designed with limited contrast in a scene precisely to cover up such defects. Anyway, simple 2x2 supersampling does not produce really great results, but it is better than nothing. A slight change to the supersampling algorithm improves things quite a lot. For each supersample quad, the sample points are rotated a small amount, say 33%, like so: | 2 1 | ------|------ | 4 3 | Now we see that a vertical polygon edge can cover: - no samples - sample 1 - samples 1 and 3 - samples 1, 2 and 3 - all samples so there are now three intermediate steps, a big improvement. This gets us into the ballpark of relatively decent. What about non-vertical, non-horizontal edges, is it possible to line up an edge so that it degenerates to a single intermediate color? In this case, the edge tends to cross the pixel grid in an irregular patterning, creating a jitter effect that prevents this degeneration. (I didn't spend too much time analyzing this, so there might be a worst case I missed.) Rotated grid supersampling can be implemented with very little hardware support. We take advantage of the fact that for pipelining reasons we are processing all interpolants separately for even and odd pixels anyway, so we just add some X and Y gradient to each interpolant, and make the adjustment different for even versus odd pixels. The adjustment is also different for even and odd scan lines. The cost is an extra add per interpolant in the span setup, and the per-trapezoid cost of calculating the adjustments. There is also a new requirement to align pixel pairs to the screen rather than to polygon edges, which requires a little extra logic to prevent the left pixel from being drawn outside the polygon. Scanout for rotated grid supersampling remains a simple average, because the weights of the samples remain equal. Quality can be further improved using a better scanout filter with wider support than two pixels, for example: 1 1 1 2 2 1 1 2 2 1 1 1 where the filter weights sum to 16, keeping the arithmetic simple. I am aware of two other popular categories of FSAA techniques: multisampling and accumulation buffer. Multisampling is considerably more complex to implement than supersampling and requires more dedicated hardware, but it is more efficient because only a single texture sample is required at each pixel. The framebuffer becomes more complex structure because it has to store a coverage value for each sample for each pixel. The big problem is that additional arithmetic is required per-pixel, per-sample. We can't afford that complexity in the rasterizer this time around, both because of the increased hardware budget and the extra time it would take to get it right. The accumulation buffer method requires a full scene to be rendered multiple times, incurring extra triangle setup and rasterization overhead. It requires application level support. It might require a scene to be passed over a bus multiple times. If there were shaders, they would be executed multiple times and a new requirement of repeatability would be added. For a similar number of samples this method should produce similar results to supersampling, but less efficiently. Timothy suggested a variant that seems to combine multisampling and an accumulation buffer at the span processing leve. I haven't seen enough details to comment, except to note that this probably introduces rendering order dependencies, which the other three methods do not. Considering the alternatives, 2x2 non-rotated supersampling seems to be the only approach that could be realistically implemented in an initial release, and which does not require application support. Rotated grid supersampling provides a significant quality boost but requires only a small amount of additional hardware support. This makes it suitable for a followup release. Multisampling should eventually be implemented because it avoids redundant evaluation of texture filtering functions. Because multisampling requires significant extra hardware support, it is not suitable for an initial release. All "in my humble opinion". Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
