RSX: Vertex input limited? *FKATCT

Isn't it true that sometimes Ati hardware is better a handling certain shaders and sometimes Nvidia hardware is better at handling certain shaders. Couldn't it be that your shaders are just more friendly to Ati hardware. I'm sure there are going to be games that pixel shaders are so optimized for the RSX that the Xenos would have alot of difficulty running them.
I remember it was said of G70 that nVidia consulted with devs about the most common shaders and optimized for those. I've no idea how that's accomplished, but it does sound the case that some architectures will be better at some generic shaders than others, not taking into account more exotic features like branching.
 
We use a job based system, a job being a single task >100,000 spu cycles. A small job manager (running on the SPUs themself) simply takes job descriptor from a main memory list and allocates that job to a free SPU.

That is awesome. I didn't expect we would see that technique being used so soon. Did Sony provide libraries for this sort of thing? Or did you have to design/implement the whole thing entirely?

To be able to get good results from this on a first gen game this is quite exciting! Hopefully other teams will pick it up fast too.
 
# Instruction slots
PS3 512
360 4.000
When you say "PS3", do you mean just "pixel shader 3" spec or "Playstation 3"? 512 is the minimum spec for SM3.0 (I believe that's the case for all those specs you have listed under "PS3"), but even the GeForce 6 series offered up to 4096 instruction slots, IIRC. Or at least the 6800, did I think. My memory for these things is horrid since I hardly ever buy new video cards. Everything I own at home predates AGP.

Perhaps I am getting something wrong but doesn't an avg. workload of 1k operations/fragment exceed the theoretical capabilities of RSX & Xenos by a factor of at least 4 at 720p/120Hz (assuming zero overdraw)?
D'oh... I just realized I should have said "everything major" -- as these are generally proof-of-concept levels, the areas are dominated by stuff that is meant to illustrate key features, and usually shading is among them. Everything else tends to get relatively lightweight stuff. All the same though, the lightweight materials rarely if ever dominate the screen (short of deliberately zooming in on something specific). And of course, I'm also counting other things besides computational instruction slots. And BTW, it's not exceeding the theoretical capacities by a factor 4.

I should also add that those were figures for one particular project. The other one has its proof-of-concept levels being enormous with really huge draw distances and very few occluded polys (lots of wide-open area), loads of full-screen effects, and so one... and we stick around 40 fps on that one -- 40 on the 360, that is. PC is lucky to get 30, and they don't have a PS3 build yet.
 
Last edited by a moderator:
That is awesome. I didn't expect we would see that technique being used so soon. Did Sony provide libraries for this sort of thing? Or did you have to design/implement the whole thing entirely?
I heard that the PS3 SDK has a library for developing job systems for SPUs and that is quite powerfull. I don't know if Ninja Theory is using it as a base of their job system.
 
Last edited by a moderator:
I heard that the PS3 SDK has a library for developing job systems for SPUs and that is quite powerfull. I don't know if Team Ninja is using it as a base of their job system.
There's SDK support for both out-of-the-box and custom SPU job management schemes, and internally we have a job manager that effectively plugs into this system which is available for teams operating as part of (or for) SCE WWS. So specifically, it's this custom job manager which Ninja Theory (*not* Team Ninja, as they are a group within Tecmo) are using.

Cheers,
Dean
 
Of course we encountered problems, we moved from PC and an early 360 version (alpha kit) to PS3. However we have the advantage of just doing whatever voodoo the PS3 requires.

However we seemed to have worked around them, without any major SPU GPU work (I personally see too much SPU time on graphics as a waste, I want the SPU to make the game better).

Our hero :D I confess my unnatural love for graphics, but what makes games great are the things that occur and how players can interact with such. When I hear such sweet love music from a developer I truly wonder how MS let you slip off their platform. I can see Allard now :runaway:

I remember it was said of G70 that nVidia consulted with devs about the most common shaders and optimized for those. I've no idea how that's accomplished, but it does sound the case that some architectures will be better at some generic shaders than others, not taking into account more exotic features like branching.

This was why they added an extra MAD (or was it a MUL? foggy... one or the other I believe) to each fragment shader in G70. So each Pixel Shader in G70 has 2 fragment shader ALUs as well as the additional MAD. Basically through testing of shaders they saw that many shaders could use an extra MAD and that the cost of offering such was cheap. At least that is how I remember it...
 
There's SDK support for both out-of-the-box and custom SPU job management schemes, and internally we have a job manager that effectively plugs into this system which is available for teams operating as part of (or for) SCE WWS. So specifically, it's this custom job manager which Ninja Theory (*not* Team Ninja, as they are a group within Tecmo) are using.

Cheers,
Dean
So as Dean say we (NT) use the WWS provided job manager, which is itself built as a custom SPU job scheduler on the standard PS3 job api (SPURS).
We (NT) also have a layer above the WWS job manager which provides a bunch of high level things to make our lives easier but all the hard work is done by WWS and the OS, Which is nice :)
 
This problem is easily fixable, just store an additional bit per vertex that let you reconstruct the original tangent basis vectors. In HS we store a bit like that in the most significant bit of the w component of our position vectors so that we to reconstruct binormals we do something like that:

float4 binormal = sign(position.w) * cross( normal, tangent );

very cheap and effective.

Yep. Same here. Works fine.

To speed up simple rendering passes as z pre passes or shadow map one just needs to split vertex data in at least 2 streams: one for position and the other one for all the rest..that way one can basicly achieve VS throughput wise some number pretty close to the theoretical capabilities of the chip.

Only problem with this approach on the 360 is that each stream forces a full vfetch (and 32 cycles), so we want to reduce the number of streams to the bare minimum. Only one wherever possible. I tend to duplicate position information for z-only rendering where it makes sense. Ugly, but faster in vertex-limited situations on the 360 and with predicated tiling always looming around...
 
Not sure why you'd laugh, its the most visually impressive console title to date. You need to play a few hours into it to see some of the best graphics though. Even if you assume that rsx by itself could do it, you then run into other PS3 limitations like less free memory available.

It must be said that most of the amazing look of GoW comes from the fantastic job done by the artists in setting up each scene, most probably greatly helped by the slick tool chain.
From a purely engine perspective, I also can't see anything that can't be done with a RSX and anything that can't be done better on the 360 in future titles, especially with engines tailored to each console's strengths and designed to exploit them.
 
It has been mentioned on this thread that the Playstation 3 has less available total RAM than the 360. I have been curious about this issue before this thread ever began.

I know that the OS reserves some portion of the RAM in both the 360 and the PS3. Can anyone here please confirm the exact amount of RAM reserved by the OS in both systems?

The last best guess that I heard is that the PS3 has 64 megabytes reserved by the OS and the 360 reserves 32 megabytes. These numbers were just someone's guess from working with a previous early devkit.

Can anyone here please settle this issue once and for all?

I believe this issue is significant to this thread because someone already said that it's difficult to port a 360 game to the PS3 because there is simply not enough room to fit all the textures in at full size. This is a very bold claim to make. It very well could be true, but it needs to be backed up with facts about the two system's OS requirements.
 
It has been mentioned on this thread that the Playstation 3 has less available total RAM than the 360. I have been curious about this issue before this thread ever began.

I know that the OS reserves some portion of the RAM in both the 360 and the PS3. Can anyone here please confirm the exact amount of RAM reserved by the OS in both systems?

The last best guess that I heard is that the PS3 has 64 megabytes reserved by the OS and the 360 reserves 32 megabytes. These numbers were just someone's guess from working with a previous early devkit.

Can anyone here please settle this issue once and for all?

I believe this issue is significant to this thread because someone already said that it's difficult to port a 360 game to the PS3 because there is simply not enough room to fit all the textures in at full size. This is a very bold claim to make. It very well could be true, but it needs to be backed up with facts about the two system's OS requirements.

It's been mentioned in this very thread that the reason developers aren't giving out the exact number of RAM reserved by the OSs is because that information is under NDA. There's no point in continuing to bug developers with those questions. They'll give you as much info as they are willing and able to give, and I think we should be thankful for it. This thread already has proved to be very informative, so thanks to the developers for all their input, it's greatly appreciated.
 
It must be said that most of the amazing look of GoW comes from the fantastic job done by the artists in setting up each scene, most probably greatly helped by the slick tool chain.
From a purely engine perspective, I also can't see anything that can't be done with a RSX and anything that can't be done better on the 360 in future titles, especially with engines tailored to each console's strengths and designed to exploit them.

err.. some people got bad rep for telling this..
But it's so true.
Most of the graphics have a static approach of lighting ,and probably a lot simple emissive cubemaps on lambert type of surfaces.A lot of detailmap (normalmap and diffuse) is making up for very hirez texturing.
Certainly a very smart job from artists ,but for developpers ,certainly not an incredible showcase of technology.

On the topic of plateform ,when we straight port our first Ps3 engine to X360 we had much better performances.Then ,becoming ps3 exclusive ,we did a lot of rethink and tuning (and up to date kits and libs) ,it 's now a lot much better than x360 's....
This Is normal ,when you have oportunity play with the strenghts.

Most multiplateform titles can't get that dedicated tailoring pass so both versions will compromise.Ports,depending on $$ pressure ,will even more.
 
Back
Top