You are describing a situation at the extreme where RSX may have some difficulty.
Not really extreme, actually fairly common for all sports games, and probably reasonably common in any game that gives the user camera control. It's amazing the amount of havoc a user controlled camera can cause with respect to optimization.
What happens in the case where both heavy vertex and pixel processing demands must be met concurrently? In this case both the vetex and fragment pipelines are available on RSX so the demand can be met. On Xenos the pipes can only be split as the ALUs can't handle both jobs at the same point in time.
RSX's vertex abilities at full tilt can't keep pace with Xenos, even if split. Maybe even if quartered
It's been argued here that pixel side RSX should be better but we haven't seen that, at least not in our shop. I suppose if we really hollowed out our pixel shaders then the split bandwidth on PS3 could prove to be an edge. But thus far, our pixel shaders still have enough instructions in them to give Xenos the edge. Mated with it's automatic load balancing, it's tough for RSX to keep pace.
This is a fidelity issue rather than extracting good performance.
It's a fidelity issue resulting from a performance issue. Believe me, we'd like to be able to just use alpha, in some cases it just plain looks better. But we can't on PS3 in this particular case due to performance issues, which in turn has now led to a fidelity issue. You would probably never notice in a shooter or faster moving games. But in baseball where it can just sit there in your face for a while, it is noticeable.
Sometimes the performance issues lead to more than just fidelity problems. Our 360/PS3 versions are almost identical, but there is for example one replay-only effect (30fps mode for replay) where we really push edram to create a nice volumetric grass. We have not been able to recreate this on PS3 at a reasonable framerate. So in this case the problem extends beyond just a visual issue. We had to cut that effect totally on PS3.
You could try different MSAA levels on the fence or perhaps dynamically alter it.
I'm not a fan of changing msaa to 0x/2x/4x on the fly, the visual incongruity it causes in this case would to me would be worse that the artifacts we're seeing in the first place!
Dr. Nick said:
I know you are just giving an example but wouldn't using something like this help on the 360 as well.
Not necessarily! It's like the obsolete art of assembly coding. Ok, that may offend a few here
But the reality is that for the most part, given the complexity of todays hardware you are better off coding in a slightly more abstracted language and just let the compiler arrange the microcode optimally for you. Overall it's likely to do a better job. That's why for example it's always strongly recommended to write shaders in hlsl and just let the compiler do the rest.
In this case, the gpu ultimately has intimate knowledge of whats going on at any given moment and is in a better position to determine what load needs to be distributed where at a given frame. We can try to help it a bit on our side, but only at a more macro level. We are better off letting Xenos do it's thing.