Alternative AA methods and their comparison with traditional MSAA*

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.
Indeed, only way to use it with normal shadow maps is in screen space and saboteur already does that.
However, I think it might work with variance shadow maps as you can already use gaussian blurs, mip-mapping and MSAA on those.
 
This sounds cool. Is this method able to be slapped on for games already in progress, or would you developers need it from the start?
 
720p at one bpp is 920kb, so they're most likely processing one quarter of the image at a time on a SPU. I wonder if 1 SPU is enough fast enough to do 4 passes including loading new data into the LS, or do they use 2 SPU's, or 4?
 
720p at one bpp is 920kb, so they're most likely processing one quarter of the image at a time on a SPU. I wonder if 1 SPU is enough fast enough to do 4 passes including loading new data into the LS, or do they use 2 SPU's, or 4?

Spu's have 256k, but some memory at the bottom is taken by spurs and your code, some memory at the top is taken by stack, and whatever is left over needs to be split in two to double buffer, so that you can be dma'ing new data to one half of that memory while processing current data in the other half. So it would need to be split into more than four parts.


Delta9 said:
This sounds cool. Is this method able to be slapped on for games already in progress, or would you developers need it from the start?

In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.
 
In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

Thanks for the input.:cool:
 
On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

So this kind of AA can also be done on 360?
 
In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

I don't understand that. If you intend to do something definitely shouldn't you budget for it from the get go? If a developer decides to put in 2xMSAA constantly in their game wouldn't it be better to develop the game with the aa already part of the process instead of waiting till later to find that such and such level doesn't play too well with aa on. At what point do you start considering what its going to take to get it working well:?:

So this kind of AA can also be done on 360?

I am wondering that as well, and how? Also what reason could there be to not work msaa into the 360 and PC builds? In the case of the PC version at least it is strange, unless its a direct port of the 360 version which would leave it with whatever reason there is no aa on the 360.
 
So this kind of AA can also be done on 360?

Yup.


I don't understand that. If you intend to do something definitely shouldn't you budget for it from the get go? If a developer decides to put in 2xMSAA constantly in their game wouldn't it be better to develop the game with the aa already part of the process instead of waiting till later to find that such and such level doesn't play too well with aa on. At what point do you start considering what its going to take to get it working well:?:

It comes down to a difference in implementation. First off, there is little incentive to do it on 360 since msaa is free on that platform. We know from peoples comments that the lack of msaa on PS3 versions is deemed not a big deal, or an "extremely minor difference", so we can conclude that the free 2x msaa on 360 is probably good enough for most. For the few games that can't use the free msaa, either because it's not compatible with their engine, or perhaps they are adverse to tiling for whatever reason, then they can consider a post process method.

Implementing this form of AA on 360 turns out to be fairly easy, easier than it would be on PS3. You don't have to carve up data, dma it back, none of that stuff. Think about it, you already have all your post process buffers sitting there in main memory, full Z, reduced Z, color, luminance, all of them totally accessible to the gpu. Just sample them in shader, easy as pie. The catch on the PS3 side is that you have to have enough spu time to spare. The catch on the 360 side is that you have to have enough gpu to spare. The reason to leave it until later in the process on 360 is to wait until your post process steps are nailed down. Then you can take advantage of it's gpu and fit the AA steps into gpu idle time in post process. It's been mentioned other times that sampling does not affect alu's on 360 unlike on PS3, so on 360 you want to move the workload around where it can be absorbed the most. You are more likely to know where the idle times are later in the project after your post process steps are more complete.
 
I'm wondering why are there so many games without MSAA on 360 if it's indeed free, are programmers truly that pressed for time? For example why didn't Pandemic use the free MSAA for Saboteur, since they had plenty of time to come up with this unique post process solution in the PS3 version? Come to think of it, it's not even in the PC version where power isn't a concern.
 
MSAA is never "free" at the very least not on these consoles. If you end up having to use tiling which can lead to performance loss I don't see how it can fairly be called free. Then there is the fact that even when it all fits into the edram nicely you can still have performance degradation (better performance without aa vs with aa means its not free). Its obviously easier than on the ps3 to implement though

What i don't get is that you are saying its possible specifically on the 360 GPU but here ppl are hoping it makes its way into future hardware. Is the 360 GPU that flexible to accept this new method? Doesn't it work through ~dx9 and aren't the things that can be done with it already defined? Or does it have nothing to do with that?
 
corduroygt said:
For example why didn't Pandemic use the free MSAA for Saboteur, since they had plenty of time to come up with this unique post process solution in the PS3 version?
The implementation being PS3 specific, there's a cost associated with adapting it to anything else. Not to mention performance characteristics on the other platform - they could have been short on time, money, performance, or all 3 of them.

Come to think of it, it's not even in the PC version where power isn't a concern.
PC is notoriously horrible platform for experimental stuff - anything non-standard is annoying to use for huge-testing time alone. And the % of userbase that really cares will probably have access to SSAA hacks etc., and hw-power to use them, so why bother.
 
I actually tested the demo MLAA code from the paper someone linked, on several images from our game and the results were stunning.
We were planning on implementing 2xMSAA, but after seeing the impressive MLAA results, we will probably implement it to at least prototype stage to see the results in motion and to measure performance. We have some ideas how to do this via the GPU. I'm not sure about some of the details but it might just work.
Let's just say I'll be extremely happy if we can avoid dealing with MSAA :)
 
I actually tested the demo MLAA code from the paper someone linked, on several images from our game and the results were stunning.
We were planning on implementing 2xMSAA, but after seeing the impressive MLAA results, we will probably implement it to at least prototype stage to see the results in motion and to measure performance. We have some ideas how to do this via the GPU. I'm not sure about some of the details but it might just work.
Let's just say I'll be extremely happy if we can avoid dealing with MSAA :)

Was it this link that Butta had posted?

http://visual-computing.intel-research.net/publications/mlaa.pdf

...also, do you go purely by luminance as well?
 
The implementation being PS3 specific, there's a cost associated with adapting it to anything else. Not to mention performance characteristics on the other platform - they could have been short on time, money, performance, or all 3 of them.

I meant why didn't Pandemic use the "free MSAA" in the 360, or one of the myriad MSAA solutions that come in PC GPU's? I wouldn't expect them to adapt the SPU AA method to other platforms that don't have SPU's. If they had the time to do a custom AA solution for the PS3, they would have time to enable the built-in AA on the PC/360 GPU's.
 
Are you working on a PS3 game?

Xbox360 and PS3. On Xbox360 there are several ways to approach this, probably all GPU based. I doubt the PPC can pull off the MLAA algorithm in real-time.

Was it this link that Butta had posted?

...also, do you go purely by luminance as well?

Yes, the Intel MLAA paper. You can find the source code here:
http://visual-computing.intel-research.net/publications/publications.htm

And indeed we're planning to work purely off the color buffer, but it will be easy to access depth and G-buffer information if necessary.
 
If a single SPU is fast enough to run it at 60fps, how about Sony adding it as a toggle in System settings in a FW update and use the reserved SPU for it. Sure it'd blur the UI as well, but all those games without AA would gain a lot from it.
 
'free' is obviously bollux or else all games would use this 'free' MSAA :)

Correct. MSAA is not free, no matter how many times Microsoft repeat that.
Even for a forward renderer, staying in HD resolution would require 2 tiles, which means extra vertex processing cost for anything that crosses a tile or is only visible in the second tile. For example, the main character of most games will probably transform twice, and is guaranteed to be skinned and with high vertex count (aka worst case).
Additionally, tiling incurs lag due to the fact that the GPU can't start rendering until the entire tiling bracket is generated on the CPU, sometimes this could be as much as a full frame (33ms for 30fps games).
For a deferred renderer it gets worse, you need 2x memory for G-buffer and Lighting buffer textures, you need 2x number of resolves, and naively will incur 2x lighting cost (could be limited to just edges with some stencil work). And if you want HDR and you want to proper MSAA blend after tone-mapping, the whole thing becomes a big mess and quite expensive.
 
Back
Top