Alternative AA methods and their comparison with traditional MSAA*

mitran

Newcomer
Mod: This thread appeared in the Console Tech forum and has centered on MLAA on the Cell processor. Although not limited to consoles, as that was the area of development it remained there. The latest development of an effective MLAA technique on GPU makes this a more open technology, so I've (finally!) moved the thread to the 3D Tech and Algorithms forum.

over @ http://blog.us.playstation.com:80/2009/11/developer-diary-3-the-saboteur-for-ps3/#comment-295128
you can read that they do FSAA on the SPU's. I ts the first time i have ever seen any dev use the SPU's in order to do FSAA. But is not FSAA something better let the GPU do?

"Tom French replied on November 13, 2009 at 6:17 pm1. 720p is our native res. We use the SPUs on the PS3 to do a full screen FSAA filter."

Sory if i am posting in the wrong forum. Perhaps they have found a fast way to do FSAA on SPU's if so do you think more dev's will try to do the same? Do it realy free up more " time" on the GPU?
 
They are probably doing MSAA resolve on SPUs. This doesn't save any time on the GPU, since RSX has dedicated hardware for this (which in this case stays idle). However such approach is programable and thay can resolve this in what ever way they want (edge detect,...). Similar to what ATI is doing on their Radeon line.
 
No not really. You still have to copy the buffer from GDDR to system memory and resolved buffer back to GDDR.
 
Thanks for the heads up. Interesting this definitely requires the full render buffer to be in the XDR memory. This was discussed in the technolgy thread before, GG only copied a quarter res buffer to XDR to do the post processing on the SPU (KZ2), but now we have an example of a full res buffer in XDR so we know it is a viable method.

Maybe FSAA is done in the same pass as the post-processing on the SPU? That would save memory bandwidth.
 
"We're using SPUs to do a full-screen antialiasing filter" sounds more plausible, where "antialiasing filter" means something like "edge detect + blur".

Tom French is not exactly a hardcore rendering programmer, judging from his MobyGames page.
 
Crossbar said:
Maybe FSAA is done in the same pass as the post-processing on the SPU? That would save memory bandwidth.
That would be a smart solution. SPU's are ideally suited to complex image processing of small tiles. The more operations you can do in a single read, the better, saving BW.
 
PS3 is lucky that it has a CPU that can cover up some of its GPU's inadequacies. ;) Workarounds-R-Us....
 
Not so much luck as design, for better or worse. We really need details on what exactly they're doing to carry this coversation forward.
 
Note: N00B question incoming

What's FSAA, and how does it compare to MSAA and regular AA (if there's anything like regular AA)?

Could doing this on the SPUs be something that's applicable in all games? And why has anyone else not thought of this if so?
 
FSAA just means Full Screen AnitAliasing. Can be MSAA or supersampling or something else. Technically an edge-based AA shouldn't be FSAA, but I don't know if anyone makes a distinction. AA is always applied across the whole screen.
 
Yes, but that AA is applied to every line across the screen. Putting it another way, MSAA only antialiases at polygon edges too. Non-edge pixels are the product of a single sample and so have no antialising applied, meaning the vast majority of pixels are not antialised, just like an AA'd line-drawing method. Yet we still call that full screen antialising. The only AA method that antialises every pixel with multiple samples is supersampling, but we still call antialiasing applied only to edges as Full Screen AA.
 
"We're using SPUs to do a full-screen antialiasing filter" sounds more plausible, where "antialiasing filter" means something like "edge detect + blur".

Tom French is not exactly a hardcore rendering programmer, judging from his MobyGames page.

WTF kind of post is this??

Sorry but what qualifies you to know what Tom's practical expertise extends to?

Beyond that what makes you think "we're using.." implies "we" == "me"...?

:???:
 
WTF kind of post is this??

Sorry but what qualifies you to know what Tom's practical expertise extends to?

Beyond that what makes you think "we're using.." implies "we" == "me"...?

:???:

No disrespect meant to Tom French; I loved Mercenaries, which seems to have been designed at least partly by him.

http://www.mobygames.com/developer/sheet/view/developerId,13698/

Mobygames said:
Thomas began his career at Interplay working on Starfleet Academy scripting missions as well as designing/scripting multiplayer modes. While finishing Starfleet he also assisted in fixing bugs in Fallout. After that he was transferred over to the newly created Black Isle division to work on Fallout 2 as a scripter where he worked on areas like New Reno, Modoc, & The Den. After F2, Thomas went on to work on all the Icewind Dale games as a programmer before being convinced to try his hand as an associate producer.

After several key players left BIS to form Obsidian, Thomas took over production responsibilities on projects Jackson and Van Buren, both which never saw the light of day as Interplay pulled the plug on BIS.

After that, Thomas started work at Pandemic Studios as a designer on Mercenaries 1 for the PS2 & XBox. With the completion of Mercs, Thomas was promoted to Lead Designer and is currently working on The Saboteur.

Lead designers in 100+ people studios usually don't get to have fun with SPUs.

Assuming some detachment on his part from the nitty-gritty details on the renderer brings his statement from the blue-sky fantasy beginnings of this thread ("MSAA resolve on the SPUs?" - which is, to my knowledge, not only impossible, but also defeats the purpose of a decent chunk of dedicated hardware in the RSX) to something more mundane and likely ("some kind of AA on the SPUs").

Don't create drama where there isn't.
 
No disrespect meant to Tom French; I loved Mercenaries, which seems to have been designed at least partly by him.

http://www.mobygames.com/developer/sheet/view/developerId,13698/



Lead designers in 100+ people studios usually don't get to have fun with SPUs.

Assuming some detachment on his part from the nitty-gritty details on the renderer brings his statement from the blue-sky fantasy beginnings of this thread ("MSAA resolve on the SPUs?" - which is, to my knowledge, not only impossible,
Impossible how so?
 
Assuming some detachment on his part from the nitty-gritty details on the renderer brings his statement from the blue-sky fantasy beginnings of this thread ("MSAA resolve on the SPUs?" - which is, to my knowledge, not only impossible, but also defeats the purpose of a decent chunk of dedicated hardware in the RSX) to something more mundane and likely ("some kind of AA on the SPUs").

Ok for starters it's far from impossible and from the little time I've spent with SPU programming and some of the performance tests I've seen I can easily see how it's both perfectly feasible given some constraints and practical given the fact that RSX sucks so bad at doing it..

Oh and you're woefully misinformed if you think FSAA on RSX is somehow free/cheap especially when most modern engines these days are using at least some form of deferred pass for shadows/lighting/particles etc..
 
Back
Top