Alternative AA methods and their comparison with traditional MSAA*

I think it's funny that there is suddenly such excitement about this.

For me, it's because I didn't know about this form of AA. Marketing and gaming press have always simplified the space to pit costly MSAA against bad AA.

Secondly, some people were very sure the SPUs can't contribute to rendering, including AA. Some highlighted that developers don't have time for SPU tricks.

It's rather fresh to see developers innovating. In fact, I am contemplating buying a copy of Saboteur to show my support.
 
I think it's funny that there is suddenly such excitement about this.

It´s definitely a novelty within game development community. It´s really interesting seeing this paradigm shift from the standard MSAA technique.
I remember there was some discussion about the AA used in CE3, I am not sure it was established which technique they used, but I remember these posts by Fran and Barbarian.

I remember I wrote in the past that Tiling on 360 is a solved problem, in the sense that a pretty optimal solution to implementing it exists.
I'm not sure anymore that Tiling is the "right" solution to the AA problem on 360. And I would also extend this to MSAA in general. It feels somehow wrong having to spend so much memory to store fragments and then use it effectively only for edges. Memory spent for MSAA on 360 translates directly to the processing cost involved in Tiling.
If I take this memory/speed hit, I want FSAA and much better quality over all.

I'm toying now with EdgeAA and in my opinion it looks very promising both in terms of speed and quality. We'll see how it goes.
....

I wholeheartedly agree with this sentiment.
The memory/performance and complications in engine design to support MSAA (and it's basically to support 2x MSAA, 4xMSAA is pretty much out of the question) feels unjustified for the tiny problem that it solves. Especially in a deferred lighting setup where it's even harder to gain from it compared to a full blown FSAA.

I got a feeling some new AA technology was cooking from the comments above and it obviously is taking place on many fronts. It is really encouraging it is taking place at mulitplat developers. It seems like the current HD consoles still have a some steam left.
 
There's also the question of the future of AA in hardware. This works so well, what changes should happen on GPUs to support advanced edge-dependent blends in future?

Well one of the things that MS pushed (and ATI followed, but Nvidia balked at) was moving towards allowing software devs greater freedom to implement AA through shaders. Unfortunately Dx10.0 without the stuff cut for Dx10.1 wasn't sufficiently fast enough.

And hardware box AA was still faster than software programmable AA. So G80 vs R600 sorta reinforced the view that hardwired AA was better than programmable AA, unfortunately.

But I think we're seeing forward movement again with regards to AA. At least I hope. I know I won't be a sad panda if fixed hardware AA disappears in favor of more flexible AA solutions.

Regards,
SB
 
Last edited by a moderator:
Of course it'll work on a CPU... performance will be the issue instead.

well yeah. I figured u can do anything on a general purpose CPU as long as you want to. I was really wondering whether the performance then would make it a fools errand. On a desktop setup I'd think the graphics work would have to go into system ram before th CPU can work on it in any way making it a massive bottleneck or would it work in a similar fashion to Phsyics where the CPU simply calculates what is where and tells the GPU what to render

But I think we're seeing forward movement again with regards to AA. At least I hope. I know I won't be a sad panda if fixed hardware AA disappears in favor of more flexible AA solutions.

Regards,
SB

What about fixed flexible AA hardware. A daughter die on future GPUs to handle physics or aa or some other specialized function designed with some flexibility
 
Last edited by a moderator:
Well one of the things that MS pushed (and ATI followed, but Nvidia balked at) was moving towards allowing software devs greater freedom to implement AA through shaders. Unfortunately Dx10.0 without the stuff cut for Dx10.1 wasn't sufficiently fast enough.

(random thoughts) What might have helped was to operate on a downsampled buffer ala the SPE's post-processing setup. And with the GPUs, also use 4xMSAA+ to help create a better edge mask (edit: from the depth buffer)...
 
...

And hardware box AA was still faster than software programmable AA. So G80 vs R600 sorta reinforced the view that hardwired AA was better than programmable AA, unfortunately.
...

Isn´t it funny (or maybe sad) that the PC hardware development kind of suffocates software innovations as the brute force increase coming each year does not encourage developers to try new ideas. Better just keep doing the same thing, just some more of it.

The invariance of the consoles actually forces develpers to try new ideas, let's hope some of them will ported back to the PC space.
 
Well, normally when you do some kind of morphological AA you are very conservative about what you consider an edge (the staircase patterns), so that shouldn't happen too often in textures, and when it does it's usually something you want to filter anyway. You can of course get sampling issues where lines that shouldn't be connected are connected and things like that (again with subpixel features).

I think I'd have to see the game in person to be convinced, it's hard to tell from internet videos. One thing I noticed in that pic Shifty had linked was that to me it looked like there was blurring going on in more areas than just edges, which seemed to soften the image a bit. It makes more sense now knowing that they are going by luminance. I also saw this pic on Eurogamer:

http://images.eurogamer.net/assets/articles//a/8/6/7/8/5/1/Saboteur_Aliasing_000.jpg.jpg

I wish the lighting was the same on each pic, but either way it still looks like the PS3 version is being overly softened. The AA looks better on the PS3 pic, but to me many texture details have been sacrificed to attain that. Admittedly I tend to be very sensitive to that, I really notice it on games like AC2, RE5, etc that look much softer on PS3 and it bugs the heck out of me. It's also why I have an extreme disdain for quinqunx aa. I'm wondering if using both luminance and Z is the better way to go. It would take some more bandwidth to shuttle Z data over to spu, but after that some simple Z checks could spare the textures the detail loss.
 
I agree that there is a bit of blurring (and just general processing) going on in Saboteur where there shouldn't be, including the UI (which I already commented on). It's a general trade-off with a purely image based method between finding too many "edges" (and thus blur) and missing some of them, and I think they may have gone a bit too far into the former direction. Still, it's the first implementation we see in a retail game and I can't blame them too much considering how much interest it has (IMHO finally) generated in this topic.
 
As I understand it AA has the heaviest bandwidth cost of nearly any function done by the GPU. Does this technique nearly completely remove this cost?

Also since this technique is done at the post processing phase, would it not be possible to perform after 2xMSAA is done?

The 2 games I would be most curious to see this applied to:

GTAIV - Aliasing was terrible in that game and the graphics were similar in look to saboteur... I have a feeling this would be a good fit

Gran Turismo 5 - This would bring this game to a nearly rendered look. Edge detection would be trivial gievn the nearly flat shaded look of the textures. I find that even 4xAA at 720p is not enough for this game. Would be curious to see the output of MLAA at 1280x1080 (if possible with 2xMSAA combined).
 
As I understand it AA has the heaviest bandwidth cost of nearly any function done by the GPU. Does this technique nearly completely remove this cost?
Talking about the PS3 particularly, obviously doing it on the SPE removes any kind of *graphics memory* bandwidth impact, which I understand to be a problem in some cases on that platform. In general in a GPGPU setting you'd want to work on pieces of the image that fit into your on-chip memory, which again greatly reduces the external bandwidth requirements.

Also since this technique is done at the post processing phase, would it not be possible to perform after 2xMSAA is done?
That's not a good idea. Getting good results out of a technique such as this depends on accurately reconstructing (the slope of) the edges based on the staircase pattern. When your "real" AA already blurs those it doesn't really help you at all.
 
Also since this technique is done at the post processing phase, would it not be possible to perform after 2xMSAA is done?

I don't understand how that would be possible. How would the algorithm detect jaggies on an already AAed image, especially if it doesn't operate on depth?
 
That's not a good idea. Getting good results out of a technique such as this depends on accurately reconstructing (the slope of) the edges based on the staircase pattern. When your "real" AA already blurs those it doesn't really help you at all.

This could be a stupid question but here it goes, why not pass the MLAA before the MSAA?
 
This could be a stupid question but here it goes, why not pass the MLAA before the MSAA?
It's not stupid, in fact it has been brought up before in this thread IIRC. You could indeed try to do the edge detection pass on the unresolved MSAA buffer (if you have access to it). That information could then be used to decide on how to blend which samples. The question is if it's worth the complications.
 
Could this technique also be used to AA shadow buffers?

Not really as that stores depth values. If you have a 'bright' and a 'black' pixel near each other, then you'd have to change both to a 'mid' level for AA but that'd mean a completely different distance value. It's like the edges of an object would be moved several meters away from the camera, and the background would meet with those edges in the middle.
 
I imagine you'd get some really strange artifacts with the lower resolution shadowmap, setting up those separation lines/borders (if you took the RGB analysis).

Could this technique also be used to AA shadow buffers?
 
Could this technique also be used to AA shadow buffers?
what you could do is something like

A/ render a shadowbuffer but when it passes write the linear distance from the light occluder to the receiving fragment
B/ on the SPUs go though this buffer doing a 'similar' technique as mentioned

or combine A+B

result = better shadows than in any existing game (I think)
 
Back
Top