New dev tools ? PlayStation 3 Edge

I don't understand why it's hard to accept that one video card is better than another.

Because I don't think it's possible (in this generation) to clearly state that one GPU is better than another in any situation and it's very hard to define the term "better". Always better? Generally better? Better at doing what?

An example might clarify my point: the 360 GPU has serious issues with alpha testing because it lacks early-z rejection at fragment level. If you have heavily alpha tested geometry with a noisy alpha texture expect your primitive to sink down a performance cliff on the 360. And it's a pretty common scenario if you try to render lots of vegetation for example. I don't know the RSX in details, but from knowing the G7X architecture I can expect the RSX to handle that scenario much better. But if I'm rendering lots of shadowmap passes, I might expect the 360 to perform better. At the end of the day it all boils down to what you are trying to do and working with each platform's strenghts in mind in my opinion.

A rather funny example (funny if you don't have to work on it :)): on the 360 you might find that a tree with five times the number of polygons renders two or three times faster! I expect that it wouldn't be so true in general on a PS3. Lesson: a certain optimisation might not work on every platform. Again this suggests that it's hard to say that one GPU is 'better' than the other without saying better at what and with what optimisations.

Fran/Fable
 
Some of those things aren't removed because they don't exist. There's no DX instruction set on the GPU for example. DirectX is handled through the driver, which interprets the DX instructions into GPU instructions. It seems to me the VS are as complete as the G70 series, which themselves have comparative limits in what they can do per cycle with vertices versus Xenos (and ATi's other GPUs?)

Thanks, for some weird reason I had gotten the idea that there was some kind of hardware support for the instruction sets. It might have been due to the DX9 debakle back when ATI had an advantage over nVidia's G6 series which weren't designed to support 24bit effects (something about MS not inviting nVidea to the DX meeting?).
But now thinking about it I can see how way off I have been. It's not about the instruction set but how the the ALUs are clustered(in lack of a better term). To support 8bit/16bit/24bit/32bit calculations a (ex.) SIMD FPU needs to support 3 32bit instructions to avoid wasting performance and not 4 like the FPUs in CELL SPEs?

This leads me to more questions, I remember some SCE CEO claiming that the 360 can't support 1080p due 10MB eDRAM not being enough when a single frame buffer takes up 8MB. Now I know it's PR talk and that Xenos is using tiling, but (seems like I'm love with this term today) with some quick math it seems to me that he was talking about a 32bit color depth, do some PS3 games render in 32bit? I'm clueless about OpenGL2.0 supporting 24bit but not working behind an API I'd guess the devs would do most effects in 24bit but (here it's again) the SPE FPUs aren't "balanced" for 24bit instructions.

Sorry if I'm taking too much advantage of your willingness to help.

That's been the argument to date. US is definitely more flexible, but in a closed-box, you can optimize the Bejezus out of the engine. You'll never have the luxury of dedicating 100% of GPU resources to vertex-only work like Xenos, but if that consistitutes only 10% of your overall workload (pie in the sky rhetorical figure), you're not at a huge disadvantage. It depends a lot on the engine. If the vertex-only work is heavily utilized on Xenos, porting that is going to be hard on RSX. Especially when the attributes that can be handled are reduced. A direct port is going to suffer. A well tailored engine looks like it won't.

Pie :smile: Finally something I'm experienced in, thanks for elaborating.

Some funny and interesting points but completely overlooked because of his signature

Can't wait to play Fable 2 even though I'm not a dog person (Please tell Peter that it's absolutely mandatory to have an alternative to the dog, a tiger, a talking parrot or a boy).

Poor guy who has to do the programming for the forrest environments which I bet Fable 2 like the first will be cluttered with. :devilish:
 
No I caught the reference, it's all good.

I just wanted to make sure you didn't think I was trying to pull a jedi mind trick when I was saying the previous comment wasn't directed at Patsu or anyone else; it really was just a general comment. ;)
 
From what I understand triangle setup is a limiting factor this gen more on PS3 but it could be the case on 360 and the next gen consoles can process much more vertex than the GPU can handle. Is it false or true?
Well, it's true that the CPUs can outstrip the GPUs' vertex moving capabilities, but I can't think of that many cases where you'd even run into such a problem. I mean, RSX's tri-setup limit of 250 million, isn't really a problem because you're probably never going to get there. That's a little over 4 million issued tris per frame at 60 fps, and you have to figure that that many tris also means a lot of game elements -- i.e. lots of AIs, lots of physics objects, lots of effects, lots of animations, lots of preprocessed "special" things, god knows what else... and at that point, the CPU is probably going to busy with too many things to be able to manage 4 million tris 60x a second.

Seems like I should dedicate my time to stalking this SMM guy if all his posts are like this and the one in this thread (might even learn something... about police restrainst).
Hmmm... looking out my window, I see... a mysterious figure among the bushes on the grassy knoll up ahead.
 
Fran said:
An example might clarify my point: the 360 GPU has serious issues with alpha testing because it lacks early-z rejection at fragment level. If you have heavily alpha tested geometry with a noisy alpha texture expect your primitive to sink down a performance cliff on the 360. And it's a pretty common scenario if you try to render lots of vegetation for example. I don't know the RSX in details, but from knowing the G7X architecture I can expect the RSX to handle that scenario much better.

Interesting, I saw the opposite. Another one of my subsystems in the game is an alpha torture test of sorts, many alpha layers on top of each other to achieve a certain affect. I had to disable this on the PS3 version because it hit the framerate too hard, on the 360 it was acceptable. This was on very low vertex geometry, very simple vertex shader, and average complexity pixel shader.

archangelmorph said:
Well its kind of hard when he uses language like "RSX sucks" when what he claims he is really saying is "RSX only such when compared with the mighty Xenos.." which after reading every thread in this post so far, I don't think anyone is disputing..

Yup thats pretty much it. RSX is better than just about all other video hardware out there, but my frame of mind was the next gen console world only, so just xenos and rsx. It's like when you go out to buy a new video card for your PC and you are looking the two latest and greatest from ati and nvidia. One will suck, the other will be bought. So "sucks" is all relative as they say. Strictly speaking, xenos and rsx both suck now that the nvidia 8800's are out ;)

one said:
Going back to Edge, it's interesting to see how GCM Replay can contribute to RSX graphics tuning. Probably those who complain about RSX were doing their work in a very poor debugging environment.
http://www.watch.impress.co.jp/game/...70316/pe39.htm
http://www.watch.impress.co.jp/game/...70316/pe40.htm

Yes, GCM Replay will help tremendously!! My old officemate actually wrote that tool, and I've been bugging him forever to sneak me a copy, which he obviously couldn't do ;( In any case it will help level the playing field a bit since right now we can use PIX on 360 to great effect to optimize the video side.
 
Xenos has bandwith up the wazoo for framebuffer operations so it should be able to handle Alpha Test scenarios very well. Yes maybe early z might not work correctly, but you're only going to be taking up fillrate. If you 'really' wanted to on both system if you are going to be running a math heavy
shader on something that's alpha tested and were concerned about performance, then doing a 'z pass' with the alpha tested texture, then doing a second pass using z equal means you can early z away all the undrawn pixel.
 
The problem is that you think those things give a platform an edge pver the other one: I say that these things are a no brainer and if there's a problem is somewhere else. You speak like you got all your facts and you know the platform very well.
I have no doubt that in a year or so, when you will have more work experience you will have changed your mind. Maybe you wil still see some problems, but you will see them somewhere else..
I never said a word about that, I've just addressed your comments about RSX.


Thanks. This and Fran's post pretty much cleared this issue up for me.
 
There seems to be a lot of bashing of the "little guy" around here. Any one pointing out flaws in either hardware or software will be under heavy fire and "lakeys" will supress the "target" by taking side. Neverthless it seems real world that the RSX vertex processing is lower than the XENOS vertex processing. But if CELL helps out RSX then it may be another story but the the question is raised if the rest of the CELL:s free time is enought to do the rest (like advanced physics, AI etc).
Lets see if Mr Jokers co worker can shed some more light on this.

Note,
"Lakeys" is not expressed as something negative but they tend to favor the one with the "most knowledge" (who is to tell who is better at coding without showing their work to each other?) or the one who favors the machine they support, thats how it is sadly. They will support them no matter what they say practically.:rolleyes:
 
Neverthless it seems real world that the RSX vertex processing is lower than the XENOS vertex processing
You have to understand that statements like that most of the time really don't make much sense cause these complex architectures change their behaviour/efficiency according an awful big number of parameters or conditions.
If we want to make sure there's no "little guy bashing" or no "he works for that publisher so they must have an agenda" trash talking we only have one and only one way: to discuss about technology and architectures as much as we're allowed to do, we'd better leave out all the rest.
Now, if we want to have a serious (and technical) discussion about any issue on any platform..I'm all for it! otherwise I call myself out.
 
Xenos has bandwith up the wazoo for framebuffer operations so it should be able to handle Alpha Test scenarios very well. Yes maybe early z might not work correctly, but you're only going to be taking up fillrate. If you 'really' wanted to on both system if you are going to be running a math heavy
shader on something that's alpha tested and were concerned about performance, then doing a 'z pass' with the alpha tested texture, then doing a second pass using z equal means you can early z away all the undrawn pixel.

Problem is Hi-Z only stores max depth for a group of pixels, so z equal after a z-pass doesn't kill fragments unfortunately. You have to use z-lessorequal. And even the z-pass itself with a very simple shader is very expansive when you are talking of degenerate scenarios with up to 2 million quads for a single tree being shaded to be rejected by alpha-testing or by being occluded and not early rejected. It's a completely shader-bound (or texture bound depending on cache coherency) scenario even in the z-pass. The optimisation here is at higher level, you have to work on the mesh itself and make it more friendly for the 360, and it starts flying. Which might make the PS3 go slower, and when you optimise for it, the 360 might go slower, and so on.

You have to understand that statements like that most of the time really don't make much sense cause these complex architectures change their behaviour/efficiency according an awful big number of parameters or conditions.

Indeed. That's the whole reason why that kind of statement can't be made in general in my opinion.

Fran/Fable
 
From my point of view all this stuff has a direct relationship with Sony policy with third parties and PS3 exclusives.

If a game is made using the RSX for the geometry it can be easily ported to 360 with a few changes, in the case of a game using the SPE for the geometry then is more harder to make a port from PS3 to 360 and the game could remain as a PS3 exclusive.

Sony know that the content is what moves the industry and they need a lot of exclusive content to win like the other 2.
 
From my point of view all this stuff has a direct relationship with Sony policy with third parties and PS3 exclusives.

If a game is made using the RSX for the geometry it can be easily ported to 360 with a few changes, in the case of a game using the SPE for the geometry then is more harder to make a port from PS3 to 360 and the game could remain as a PS3 exclusive.

Sony know that the content is what moves the industry and they need a lot of exclusive content to win like the other 2.

Interesting theory...

However its a shame that ease of development is practically never the defining factor as to whether a game remains exclusive to a platform or not..
 
Urian, this may have true in the last generation, but development cost together with publisher profits mean that most games this gen will be multiplatform. This seems to me to suggest that developers want tools that make crossplatform development cheap and easy. I just can't see either Sony nor MS swallowing the costs or risks involved in exclusive titles, timed maybe.
 
If a game is made using the RSX for the geometry it can be easily ported to 360 with a few changes, in the case of a game using the SPE for the geometry then is more harder to make a port from PS3 to 360 and the game could remain as a PS3 exclusive.

This again cannot be generalized. Since Xenos is a unified architecture, this heavily depends on the relation of PS to VS work that is done on the RSX.

If the engine was totally maxed out to use all of these units on RSX by 100% (theoretically) then i doubt you can easily port this to Xenos.

(And i've yet to see a game ported from PS3 to 360, til now it's always been the other way round afaik)
 
I'm also wondering if there couldn't be a potential gain from letting the CELL handling culling and such when it comes to more "dynamic" graphics (again, I'm a complete noob going on a limb here) procedurally generated water waves interacting with a ship.

Always wanted an object like a pillow act like an actual pillow and not just being a "rock" with a pillow painted on it presented in the context of a bed.

But maybe I'm just holding nVidea and Sony in too high regards, in reality they could just be fumbling around without a clue.

Am I completely way off with my presumption? I just thought that with the CELL SPEs presumably being better at branching than the RSX VS pipelines it would be an idea to let them handle vertex shading in these scenarios.

This again cannot be generalized. Since Xenos is a unified architecture, this heavily depends on the relation of PS to VS work that is done on the RSX.

If the engine was totally maxed out to use all of these units on RSX by 100% (theoretically) then i doubt you can easily port this to Xenos.

(And i've yet to see a game ported from PS3 to 360, til now it's always been the other way round afaik)

But as so many have said in this thread already, you can't just allocate all the shader pipelines to do VS as you still need to do PS.

Am I mistaken if I say the RSX may have more powerful PS pipelines potentially making the porting even more complex?
 
Am I completely way off with my presumption? I just thought that with the CELL SPEs presumably being better at branching than the RSX VS pipelines it would be an idea to let them handle vertex shading in these scenarios.

VS branching is good on the RSX, only PS branching is quite slow.
 
Back
Top