The Return of Supersample AA

Over the years, the methods used to implement anti-aliasing on video cards have bounced back and forth. The earliest generation of cards such as the 3Dfx Voodoo 4/5 and ATI and NVIDIA’s DirectX 7 parts implemented supersampling, which involved rendering a scene at a higher resolution and scaling it down for display. Using supersampling did a great job of removing aliasing while also slightly improving the overall quality of the image due to the fact that it was sampled at a higher resolution.

But supersampling was expensive, particularly on those early cards. So the next generation implemented multisampling, which instead of rendering a scene at a higher resolution, rendered it at the desired resolution and then sampled polygon edges to find and remove aliasing. The overall quality wasn’t quite as good as supersampling, but it was much faster, with that gap increasing as MSAA implementations became more refined.

Lately we have seen a slow bounce back to the other direction, as MSAA’s imperfections became more noticeable and in need of correction. Here supersampling saw a limited reintroduction, with AMD and NVIDIA using it on certain parts of a frame as part of their Adaptive Anti-Aliasing(AAA) and Supersample Transparency Anti-Aliasing(SSTr) schemes respectively. Here SSAA would be used to smooth out semi-transparent textures, where the textures themselves were the aliasing artifact and MSAA could not work on them since they were not a polygon. This still didn’t completely resolve MSAA’s shortcomings compared to SSAA, but it solved the transparent texture problem. With these technologies the difference between MSAA and SSAA were reduced to MSAA being unable to anti-alias shader output, and MSAA not having the advantages of sampling textures at a higher resolution.

With the 5800 series, things have finally come full circle for AMD. Based upon their SSAA implementation for Adaptive Anti-Aliasing, they have re-implemented SSAA as a full screen anti-aliasing mode. Now gamers can once again access the higher quality anti-aliasing offered by a pure SSAA mode, instead of being limited to the best of what MSAA + AAA could do.

Ultimately the inclusion of this feature on the 5870 comes down to two matters: the card has lots and lots of processing power to throw around, and shader aliasing was the last obstacle that MSAA + AAA could not solve. With the reintroduction of SSAA, AMD is not dropping or downplaying their existing MSAA modes; rather it’s offered as another option, particularly one geared towards use on older games.

“Older games” is an important keyword here, as there is a catch to AMD’s SSAA implementation: It only works under OpenGL and DirectX9. As we found out in our testing and after much head-scratching, it does not work on DX10 or DX11 games. Attempting to utilize it there will result in the game switching to MSAA.

When we asked AMD about this, they cited the fact that DX10 and later give developers much greater control over anti-aliasing patterns, and that using SSAA with these controls may create incompatibility problems. Furthermore the games that can best run with SSAA enabled from a performance standpoint are older titles, making the use of SSAA a more reasonable choice with older games as opposed to newer games. We’re told that AMD will “continue to investigate” implementing a proper version of SSAA for DX10+, but it’s not something we’re expecting any time soon.

Unfortunately, in our testing of AMD’s SSAA mode, there are clearly a few kinks to work out. Our first AA image quality test was going to be the railroad bridge at the beginning of Half Life 2: Episode 2. That scene is full of aliased metal bars, cars, and trees. However as we’re going to lay out in this screenshot, while AMD’s SSAA mode eliminated the aliasing, it also gave the entire image a smooth makeover – too smooth. SSAA isn’t supposed to blur things, it’s only supposed to make things smoother by removing all aliasing in geometry, shaders, and textures alike.


8x MSAA   8x SSAA

As it turns out this is a freshly discovered bug in their SSAA implementation that affects newer Source-engine games. Presumably we’d see something similar in the rest of The Orange Box, and possibly other HL2 games. This is an unfortunate engine to have a bug in, since Source-engine games tend to be heavily CPU limited anyhow, making them perfect candidates for SSAA. AMD is hoping to have a fix out for this bug soon.

“But wait!” you say. “Doesn’t NVIDIA have SSAA modes too? How would those do?” And indeed you would be right. While NVIDIA dropped official support for SSAA a number of years ago, it has remained as an unofficial feature that can be enabled in Direct3D games, using tools such as nHancer to set the AA mode.

Unfortunately NVIDIA’s SSAA mode isn’t even in the running here, and we’ll show you why.


5870 SSAA


GTX 280 MSAA


GTX 280 SSAA

At the top we have the view from DX9 FSAA Viewer of ATI’s 4x SSAA mode. Notice that it’s a rotated grid with 4 geometry samples (red) and 4 texture samples. Below that we have NVIDIA’s 4x MSAA mode, a rotated grid with 4 geometry samples and a single texture sample. Finally we have NVIDIA’s 4x SSAA mode, an ordered grid with 4 geometry samples and 4 texture samples. For reasons that we won’t get delve into, rotated grids are a better grid layout from a quality standpoint than ordered grids. This is why early implementations of AA using ordered grids were dropped for rotated grids, and is why no one uses ordered grids these days for MSAA.

Furthermore, when actually using NVIDIA's SSAA mode, we ran into some definite quality issues with HL2: Ep2. We're not sure if these are related to the use of an ordered grid or not, but it's a possibility we can't ignore.


4x MSAA   4x SSAA

If you compare the two shots, with MSAA 4x the scene is almost perfectly anti-aliased, except for some trouble along the bottom/side edge of the railcar. If we switch to SSAA 4x that aliasing is solved, but we have a new problem: all of a sudden a number of fine tree branches have gone missing. While MSAA properly anti-aliased them, SSAA anti-aliased them right out of existence.

For this reason we will not be taking a look at NVIDIA’s SSAA modes. Besides the fact that they’re unofficial in the first place, the use of a rotated grid and the problems in HL2 cement the fact that they’re not suitable for general use.

Angle-Independent Anisotropic Filtering At Last AA Image Quality & Performance
POST A COMMENT

327 Comments

View All Comments

  • mapesdhs - Saturday, September 26, 2009 - link


    MODel3 writes:
    > 1.Geometry/vertex performance issues ...
    > 2.Geometry/vertex shading performance issues ...

    Would perhaps some of the subtests in 3DMark06 be able to test this?
    (not sure about Vantage, never used that yet) Though given what Jarred
    said about the bandwidth and other differences, I suppose it's possible
    to observe large differences in synthetic tests which are not the real
    cause of a performance disparity.

    The trouble with heavy GE tests is, they often end up loading the fill
    rates anyway. I've run into this problem with the SGI tests I've done
    over the years:

    http://www.sgidepot.co.uk/sgi.html">http://www.sgidepot.co.uk/sgi.html

    The larger landscape models used in the Inventor tests are a good
    example. The points models worked better in this regard for testing
    GE speed (stars3/star4), but I don't know to what extent modern PC
    gfx is designed to handle points modelling - probably works better
    on pro cards. Actually, Inventor wasn't a good choice anyway as it's
    badly CPU-bound and API-heavy (I should have used Performer, gives
    results 5 to 10X faster).

    Anyway, point is, synthetic tests might allow one to infer that one
    aspect of the gfx pipeline is a bottleneck when infact it isn't.

    Ages ago I emailed NVIDIA (Ujesh, who I used to know many moons ago,
    but alas he didn't reply) asking when, if ever, they would add
    performance counters and other feedback monitors to their gfx
    products so that applications could tell what was going on in the
    gfx pipeline. SGI did this ages years ago, which allowed systems like
    IR to support impressive functions such as Dynamic Video Resizing by
    being able to monitor frame by frame what was going on within the gfx
    engine at each stage. Try loading any 3D model into perfly, press F1
    and click on 'Gfx' in the panel (Linux systems can run Performer), eg.:

    http://www.sgidepot.co.uk/misc/perfly.gif">http://www.sgidepot.co.uk/misc/perfly.gif

    Given how complex modern PC gfx has become, it's always been a
    mystery to me why such functions haven't been included long ago.
    Indeed, for all that Crysis looks amazing, I was never that keen on
    it being used as a benchmark since there was no way of knowing
    whether the performance hammering it created was due to a genuinely
    complex environment or just an inefficient gfx engine. There's still
    no way to be sure.

    If we knew what was happening inside the gfx system, we could easily
    work out why performance differences for different apps/games crop
    up the way they do. And I would have thought that feedback monitors
    within the gfx pipe would be even more useful to those using
    professional applications, just as it was for coders working on SGI
    hardware in years past.

    Come to think of it, how do NVIDIA/ATI even design these things
    without being able to monitor what's going on? Jarred, have you ever
    asked either company about this?

    Ian.

    Reply
  • JarredWalton - Saturday, September 26, 2009 - link

    I haven't personally, since I'm not really the GPU reviewer here. I'd assume most of their design comes from modeling what's happening, and with knowledge of their architecture they probably have utilities that help them debug stuff and figure out where stalls and bottlenecks are occurring. Or maybe they don't? I figure we don't really have this sort of detail for CPUs either, because we have tools that know the pipeline and architecture and they can model how the software performs without any hardware feedback. Reply
  • MODEL3 - Thursday, October 1, 2009 - link

    I checked the web for synthetic geometry tests.
    Sadly i only found 3dMark Vantage tests.
    You can't tell much from them, but they are indicative.

    Check:

    http://www.pcper.com/article.php?aid=783&type=...">http://www.pcper.com/article.php?aid=783&type=...

    GPU Cloth: 5870 is only 1,2X faster than 4890. (vertex/geometry shading test)
    GPU Particles: 5870 is only 1,2X faster than 4890. (vertex/geometry shading test)

    Perlin Noise: 5870 is 2,5X faster than 4890. (Math-heavy Pixel Shader test)
    Parallax Occlusion Mapping: 5870 is 2,1X faster than 4890. (Complex Pixel Shader test)

    All the above 4 tests are not bandwidth limited at all.
    Just for example, if you check:

    http://www.pcper.com/article.php?aid=674&type=...">http://www.pcper.com/article.php?aid=674&type=...

    You will see that a 750MHz 4870 512MB is 20-23% faster than a 625MHz 4850 in all the above 4 tests, so the extra bandwidth (115,2GB/s vs 64GB/s) it doesn't help at all.
    But 4850 is extremely bandwidth limited in the color fillrate test (4870 is 60% faster than 4850)

    Also it shouldn't be a problem of the dual rasterizer/dual SIMDs engine efficiency since synthetic Pixel Shader tests is fine (more than 2X) while the synthetic geometry shading tests is only 1,2X.

    My guess is ATI didn't improve the classic geometry set-up engine and the GS because they want to promote vertex/geometry techniques based on the DX11 tesselator from now on.
    Reply
  • Zool - Friday, September 25, 2009 - link

    In Dx11 the fixed tesselation units will do much finer geometry details for much less memmory space and on chip so i think there isnt a single problem with that. Also the compute shader need minimal memory bandwith and can utilize plenty of idle shaders. The card is designed with dx11 in mind and it isnt using the wholle pipeline after all. I wouldnt make too early conclusions.(I think the perfomance will be much better after few drivers)

    Reply
  • MODEL3 - Saturday, September 26, 2009 - link

    The DX11 tesselator in order to be utilized must the game engine to take advantage of it.
    I am not talking about the tesselator.
    I am talking about the classic Geometry unit (DX9/DX10 engines) and the Geometry Shader [GS] (DX10 engines only).

    I'll check to see if i can find a tech site that has synthetic bench for Geometry related perf. and i will post again tomorrow, if i can find anything.

    Reply
  • JarredWalton - Friday, September 25, 2009 - link

    It's worth noting that when you factor in clock speeds, compared to the 5870 the 4870X2 offers 88% of the core performance and 50% more bandwidth. Some algorithms/games require more bandwidth and others need more core performance, but it's usually a combination of the two. The X2 also has CrossFire inefficiencies to deal with.

    More interesting perhaps is that the GTX 295 offers (by my estimates, which admittedly are off in some areas) roughly 10% more GPU shader performance, about 18.5% more fill rate, and 46% more bandwidth than the HD 5870. The fact that the HD 4870 is still competitive is a good sign that ATI is getting good use of their 5 SPs per Stream Processor design, and that they are not memory bandwidth limited -- at least not entirely.
    Reply
  • SiliconDoc - Wednesday, September 30, 2009 - link

    The 4870x2 has somewhere around "double the data paths" in and out of it's 2 cpu's. So what you have with the 5870 putting as some have characterized " 2x 770 cores melded into one " is DOUBLE THE BOTTLENECK in and out of the core.
    They tried to compensate with ddr5 1200/4800 - but the fact remains, they only get so much with that "NOT ENOUGH DATA PATHS/PINS in and out of that gpu core."
    Reply
  • cactusdog - Friday, September 25, 2009 - link

    Omg these cards look great. Lol Silicon Doc is so gutted and furious he is making hmself look like a dam fool again only this time he should be on suicide watch...Nvidia cards are now obsolete..LOL. Reply
  • mapesdhs - Friday, September 25, 2009 - link


    Hehe, indeed. Have you ever seen a scifi series called, "They Came
    From Somewhere Else?" S.D.'s getting so worked up, reminds me of
    the scene where the guy's head explodes. :D

    Hmm, that's an alternative approach I suppose in place of post
    moderation. Just get someone so worked up about something they'll
    have an aneurism and pop their clogs... in which case, I'll hand
    it back to Jarred. *grin*

    Ian.

    Reply
  • SiliconDoc - Friday, September 25, 2009 - link

    That is quite all right, you fellas make sure to read it all, I am more than happy that the truth is sinking into your gourds, you won't be able to shake it.
    I am very happy about it.
    Reply

Log in

Don't have an account? Sign up now