[DeanoC]

Originally Posted by joker454

We do Although we are definitely not using them as effectively as we could. We're only using 1 spu at the moment as well. Shamefull, I know ;( But, I plan to devote a chunk of 2007 to making better use of threads on both PS3 and 360. My current thought is to make numerous 'threadlets', each being an extremely simple process that has one specific purpose, and snoozes and waits to be fed data for processing. We'll definitly be making full use of the spu's in '07.

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. Each job runs to completion, so you have a simply co-operative multitasking system. One key point is that a job can create new jobs, which allows a single SPU job to kick off a lots of other jobs, providing autonomy from the PPU.
We use the facility in the army code, an SPU job is kicked off, this does a spatial hierachy job division. Each new sub job then does a localised AI/Physics update for the soldiers inside that small part of the battlefield.
Per frame (in the army sections) we might have ~500 jobs, covering animations (DeanA the man with the details, but essentialy we batch something like 32 animation updates per job), army AI/Physics, rendering, procedural (i.e. hair & flags), frustra culling and clipping, etc.

[Shezad]

Originally Posted by MasterDisaster

could be this different capabilities the reasons that makes xenos faster in your code?

Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

[DeanoC]

Originally Posted by "Nerve-Damage"

So if nAo and the rest of the Ninja Theory clan aren’t seeing or experiencing any of these PS3 issues (not enough memory, memory bandwidth issues, RSX stalling, ETC…) which other developers maybe experiencing, then the Ninja Theory team should be commended. Developer’s who write their own straight to the mantel PS3 code, will undoughtedly yield better results than a developer porting multiplatform Unicode. And the same applies to the Xbox 360.

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).

[MasterDisaster]

Originally Posted by Shezad

Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

this is a very useful information, can you elaborate more about those operations and the other things related?

[matrix960]

Maybe I'm wrong but vertex shader unit (in term of gflops/real performance) were not very very good. Some companies wanted to use GPU to help CPU in common tasks and don't achieve one tenth of the number given by Nvidia or ATI. So with all the power in Cell, it would very useful in games when coorectly used because :

8 vertex shader at 500 Mhz (or 550) versus 6 SPE at 3.2 GHz, that must make a difference, isn't it?

[reilo]

This is a great thread. What a breath of fresh air from System Wars at Gamespot

I have a question... I don't know if this is the appropriate question to ask or not.

Everywhere I read it says that the PS3 is crippled by the split-memory, and that developers are restricted to essentially 256MB from the GPU for textures, and that developers have a hard time with that, but what about the 256MB of system memory? Can developers go about and use that 256MB of system memory for textures, or is that not possible? Can someone clear this up, because I have not been able to find any conclusive answer(s) as to why this is such a huge problem (as said by certain people). Or is it even a problem?

["Nerve-Damage"]

Can developers go about and use that 256MB of system memory for textures, or is that not possible?

Yes the XDR is accessible for textures…all 256MB of it…I don’t think so. There’s other things going on in PS3 (OS, code, ETC…) that requires XDR memory also.

[MasterDisaster]

Originally Posted by reilo

Everywhere I read it says that the PS3 is crippled by the split-memory, and that developers are restricted to essentially 256MB from the GPU for textures, and that developers have a hard time with that, but what about the 256MB of system memory? Can developers go about and use that 256MB of system memory for textures, or is that not possible? Can someone clear this up, because I have not been able to find any conclusive answer(s) as to why this is such a huge problem (as said by certain people). Or is it even a problem?

from what I know RSX can't reach directly the system memory but it have to pass trought cell adding ome serious latencies

the simple scheme is

DDR3<-->RSX<--------->CELL<-->XDR

DDR3 can hardy used as main memory from the system (if it can ve used at all)

from a dev perspective the texture flow from the memory have to be constant as possible, I thought that FB and textures are mainly stored in Vram, and other textures used less often can be stored in sysram
I think this can put some serious limitations to the overall amount of critical-mission textures of the scene, but I'm not a ps3 dev plu some further limitations (I think of how hard can it be to rsx and cell to work on the same large data without duplicate this), so wait for some exact information by nAo, deanoC, joker454 and others for more educated and precise informations.

["Nerve-Damage"]

Originally Posted by reilo

Yeah, I understood that much, I am just more curious if this poses a challenge to developers or if it was just fud.

All systems pose a challenge, no matter how good the programmer and dev-tools are. Xbox 360 may have the advantage over PS3 as being more programmer friendly, but that doesn’t elevate it from certain bottlenecks the system has. Balance is the key…

[MasterDisaster]

Originally Posted by "Nerve-Damage"

There’s other things going on in PS3 (OS, code, ETC…) that requires XDR memory also.

I've read somewhere that the OS keeps a separate frame buffer for OS function while a game is running (32 MB in Vram), don't know if it's correct but it make sense to me
never heard a single word about code which uses Vram, can you elaborate?

Xbox 360 may have the advantage over PS3 as being more programmer friendly, but that doesn’t elevate it from certain bottlenecks the system has. Balance is the key

Since I thought that all the custom hardware makes of the 360 a very well balanced machine, can you elaborate further, please?

[reilo]

Originally Posted by MasterDisaster

I've read somewhere that the OS keeps a separate frame buffer for OS function while a game is running (32 MB in Vram), don't know if it's correct but it make sense to me
never heard a single word about code which uses Vram, can you elaborate?

Some have speculated that since Sony said that a game developer can create a custom OS as they wish and please -- correct me if I am wrong NT devs -- that it is potentially possible that Sony will release libraries to be stored in that "reserved for OS" SPE and allocated RAM.

Again, this is just what I hear, and take it with a grain of salt. I am not a dev.

[Squeak]

Any way you PS3/360 devs. can tell us exactly how much memory is free to use on either machine? I mean how much is locked and set aside for the OS?

Concerning texturing from XDR, is the latency really anything to worry about, since there is no way you are ever going to be able to splash all 256MB on the screen in any one frame in a normal game? Won't there be plenty of time to fetch textures between frames?

[deathkiller]

Originally Posted by Squeak

Any way you PS3/360 devs. can tell us exactly how much memory is free to use on either machine? I mean how much is locked and set aside for the OS?

I think that you are asking for infromation protected by NDA and they already have said more than they should in that deparment.

Originally Posted by Squeak

Concerning texturing from XDR, is the latency really anything to worry about, since there is no way you are ever going to be able to splash all 256MB on the screen in any one frame in a normal game? Won't there be plenty of time to fetch textures between frames?

Are you talking about moving the textures to the VRAM? if not you have a problem with the GPU cache size, you can't fech textures for the next frame because the cache is limited.

[PiNkY]

Originally Posted by ShootMyMonkey

I don't know what you qualify as 'crazy expensive', but we have little trouble maintaining 120 fps on both machines even with shaders of a few thousand instructions and 8 textures minimum on everything. Can't say that we approach the 5-figures range yet, though.

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)?

[DeanoC]

Originally Posted by Shezad

Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

There is a technique that makes constant changes quite cheap on RSX, but discussion is not for here...

And neatly hooking up with another question, texturing (note NV also consider other things as a texture fetch) from XDR is fine. The hardware is designed to cope with it fairly well, there are some caveats but they probably only become a problem with very simple shaders.
The main problem you find, is that given up some of your precious main ram for graphics can be a hard pill to swallow.

[-=P3tRaN=-]

Originally Posted by london-boy

What does FKATCT mean?

"formerly known as the Charlatan thread"





joker welcome to this board! looking forward with interest to read your opinions.
cheers


p.s.
with all this talk from NT team, I am pretty hyped for the game!!! good stuff!

[Shifty Geezer]

Originally Posted by Dr. Nick

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.

[almighty]

Originally Posted by joker454

You can't do this on PS3 because its 720-1080 hardware scaler is broken, so you'd have to scale it in software which takes up more of those precious cycles.

So PS3 does have a hardware scaler? i thought it was software only

[inefficient]

Originally Posted by DeanoC

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.

[ShootMyMonkey]

# 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.

Originally Posted by PiNkY

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.

[Carl B]

Originally Posted by almighty

So PS3 does have a hardware scaler? i thought it was software only

It's not 'broken' either as implied... it's just inaccessible to games.

[deathkiller]

Originally Posted by inefficient

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.

[DeanA]

Originally Posted by deathkiller

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

[22psi]

Originally Posted by deathkiller

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.

Do you mean Ninja Theory?

[Acert93]

Originally Posted by DeanoC

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 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

Originally Posted by Shifty Geezer

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...