Jump to content
  • Advertisement
Sign in to follow this  
Promit

What part of the pipeline does antialiasing slow down?

This topic is 4759 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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!