Sign in to follow this  

What part of the pipeline does antialiasing slow down?

This topic is 4544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Does antialiasing create more workload on the pixel pipeline? Or is it some kind of post process that is independent of the shaders and such that you're using? TBH, I'm a little unclear how antialiasing generally works.

Share this post


Link to post
Share on other sites
Antialiasing increases the number of fragments per pixel, and averages the color values for all the fragments in a pixel to find the pixel's final value. "pixel pipeline" is a misnomer; it's really a "fragment pipeline". Without antialiasing, there is one fragment per pixel; the location of that fragment is in the middle of the pixel, and its size is the size of the pixel. with antialiasing, there are two or more fragments per pixel, each smaller than the pixel and located in different locations within the pixel. The shader will be called per-fragment, not per-pixel.

Share this post


Link to post
Share on other sites
Quote:

The shader will be called per-fragment, not per-pixel.


This is where the different antialiasing terms confuse me because I've read that multisampling doesn't, in general, significantly increase the pixel workload and I thought multisampling was a type of antialiasing - a type that only really antialiases at mesh silhouettes - and interior mesh edges at material boundaries. I guess there are other types of antialiasing but I'd imagine multisampling would be the most useful (aside from the new types on the 7800).

My understanding of multisampling is that if a pixel is completely inside a triangle (ie, all the pixel's multisample fragments are inside triangle) then the pixel shader only gets called once and it's colour is written to all fragments so the only increase in pixel shader usage above no multisampling is at triangle edges (even the interior edges where it typically has no visual effect - unless there's a material boundary where either side of edge uses different textures/shaders). So unless your triangles are on the order of a few pixels then multisampling shouldn't significantly increase pixel shader cost AFAIK.

Share this post


Link to post
Share on other sites
To elaborate further, antialiasing is only a bottleneck once per frame, when the back buffer is copied to the front buffer. You can look up multisampling (or supersampling) for a description of how it's done. In either case, it's independent of the shaders available to the programmer, since it's usually a hardwired algorithm specifically for that case. As Sneftel said, it involves multiple fragments per pixel, which translates to increased memory bandwidth requirements and some ALU ops per pixel.

Share this post


Link to post
Share on other sites
Quote:
Original post by outRider
To elaborate further, antialiasing is only a bottleneck once per frame, when the back buffer is copied to the front buffer.


But isn't it also causing more fragments to be generated, thus putting more stress on the pixel pipelines?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Promit
Quote:
Original post by outRider
To elaborate further, antialiasing is only a bottleneck once per frame, when the back buffer is copied to the front buffer.


But isn't it also causing more fragments to be generated, thus putting more stress on the pixel pipelines?


It's only a problem with supersampling, since you're effectively rendering everything onto a higher resolution back buffer then scaling that down while copying to the front buffer.

For multisampling only triangle edges are rendered at a higher resolution to the multisample back buffer. Then when copying to the front buffer they are averaged to produce anti-aliased edges. Triangle edges make up relatively fewer pixels of the final scene, compared to texels and other triangle fillers, so the penalty when rendering to a multisample back buffer is not as big as with a super sampled back buffer. The back buffer to front buffer copy is also cheaper than the supersampling equivalent.

The bigger bottleneck is still the back to front copy, since when rendering to a multisampled back buffer all you're doing is 2/4/6/8x writes for each edge pixel, where as when copying to the front buffer you're doing 2/4/6/8x reads, an average, then a dependent write.

Share this post


Link to post
Share on other sites
That was me again, who knows why I got logged out...

I should add that you're right, I wasn't strictly correct when I said antialiasing was only a bottleneck once per frame, I should have said that with multisampling most of the work was being done once per frame, but with supersampling you're eating up fillrate everywhere, as you noticed. It's also why most GPUs don't use supersampling, no sense in filtering texels again, since they're already filtered more efficiently earlier in the pipeline.

Share this post


Link to post
Share on other sites
Quote:

For multisampling only triangle edges are rendered at a higher resolution to the multisample back buffer.


I was wondering what you meant since the framebuffer (colour+z) is a higher resolution in RAM and hence still has to get written to for triangle-interior pixels. Then I read Multisampling Anti-Aliasing: A Closeup View and I realise you mean bandwidth compression.

Excerpt from that article...
"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."

...and...

"To a large extent multisampling is fillrate free, and if both colour and Z compression are offered, only little additional bandwith is used. Therefore such anti-aliasing nearly is "for free". It can be expected that future games will account for potential multisampling problems and that, as a result, supersampling gets less and less important."

Share this post


Link to post
Share on other sites
the only "issue" with it is: it will generate more fragments at the triangle edges. that means, a very detailed, high polygon mesh, creates really much fragments, as the triangles get close to pixel-sized. then, it effectively will be as costy as supersampling.

but now, with the antialiased alphatests, it starts to look really nice and efficient.

but both multi and supersampling cost the same amount of additional memory, am i right at that?

Share this post


Link to post
Share on other sites
So basically the cost of antialiasing a scene is determined by the amount of geometry. The size of polygons obviously matters, but the number of polys is probably far more important. Right?

And when I'm setting antialiasing in a game or the control panel or whatever, this is multisampling, not supersampling?

Share this post


Link to post
Share on other sites
Quote:
Original post by davepermen
but both multi and supersampling cost the same amount of additional memory, am i right at that?


As far as I know yes. For a 640x480 front buffer and 2x multisampling you'll get a 1280x480 back buffer. With 4x multisampling a 1280x960 back buffer, and so on. With 4x you'll obviously have 4 back buffer pixels for every front buffer pixel, but if a fragment is completely in the triangle interior, only 1 of the 4 pixels will be written (probably the upper left), and when the back to front copy happens only 1 will be read. For edges however all 4 are written, then read and averaged to produce a single pixel in the front buffer.

Quote:
Original post by Promit
So basically the cost of antialiasing a scene is determined by the amount of geometry. The size of polygons obviously matters, but the number of polys is probably far more important. Right?

And when I'm setting antialiasing in a game or the control panel or whatever, this is multisampling, not supersampling?


Yes, with multisampling each visible triangle edge incurs a tiny speed hit both in the triangle setup stage and the back to front copy. In reality it's not a significant penalty (as compared to supersampling) considering the ratio of edge fragments to interior fragments in a typical scene. The bigger hit between the two is in the back to front copy, simply because 4 reads from the back buffer + average + dependent write to the front buffer is always much slower than 4 (probably independent and therefore parallel) writes to the back buffer in the triangle setup unit.

And I am not aware of any consumer hardware that uses supersampling, so yes you are most-likely setting multisampling.

Quote:
Original post by Soiled
Someone in another thread mentioned Humus' Alpha to Coverage demo which apparently only works under OpenGL unfortunately. The alpha value determines the percentage of sub-pixels to cover - looks really good.


Very nice. I'll have to bookmark that one.

Share this post


Link to post
Share on other sites
Quote:
And I am not aware of any consumer hardware that uses supersampling, so yes you are most-likely setting multisampling


The 7800GTX, and one of the modes in ATi's upcoming Crossfire setup does supersampling. I would also expect that all NV and ATi cards from here on out do supersampling as well.

What I'm wondering is, how could I, in my program, set the AA modes to supersampling? I thought that in D3D you can only set multisample levels.

Share this post


Link to post
Share on other sites
Multi sample anti aliasing does not increase the number of fragments (if you use the term "fragment" in the way the OpenGL spec uses it) but the number of *samples*. The two are not identical. The fragment shader is run once per fragment generating a single colour value and multiple samples containg depth and stencil are output (unless the shader outputs depth then all samples have the same dpeth values). So multisample AA requires worst case storage cost for as many colour and depth/stencil values as there are samples per pixel, but a single fragment generates only *one* colour value. This sample buffer is then resolved before display into a single colour value per pixel.

Multi sample AA generally stresses memory bandwidth and fillrate if you use lots of samples. Most modern graphics chip sets can generate two samples per clock for free, so e.g. 4 samples cost you an extra clock. Memory bandwidth also increases with the number of samples but not as much as you might think due to compression. Most of the area of a given triangle has identical depth/stencil and colour values, most of that is required at the edges, so you can save bandwidth. Of course, the smaller the triangles are, the less true this becomes.

Share this post


Link to post
Share on other sites
GameCat is right.

Multi-sample AA works by figuring out coverage info ( in/out of triangle ) for multiple samples per pixel.

There are several things that can slow you down when MSAA is on, but the most common major cost is memory bandwidth to the larger color & depth/stencil buffers. There is also a memory bandwidth cost when filtering the large buffers into the front buffer. This can happen via the equivalent of a StretchRect() or in the DAC itself.

The other, less common things that can cause AA to slow down include :

1) Smaller triangles are drawn when using AA, b/c they only have to touch one of several samples, rather than the pixel center, in order to be rasterized. This puts more strain on the setup engine, and rasterizer, due to less efficiency when triangles are less than 2x2 samples in size. This also hurts color compression and z compression efficiency.

2) AA may slow down if the driver can't allocate compression resources for the back buffer and/or z buffer, or fails to allocate Z cull resources to the correct z buffer. This can happen in games with a lot of render to texture.

3) The larger back & z buffers take up more video memory, and may evict textures.




Share this post


Link to post
Share on other sites

This topic is 4544 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this