krik said:
crumas2 said:
Zero Hero said:
Can you 2 please keep on talking about the technical side of how games work? I'm finding the conversation very enjoyable to read. Do you both agree that the reason the PS3 is usually on the worse end of the stick when it comes to ports is the lack of using the SPE's?
Do either of you know what is needed to program for different SPEs and how it is so much more difficult to do?
On topic, I love Uncharted. My wife came into the room when I was playing it and asked me what movie I was watching. She was surprised to see a controller in my hand. |
I'm not certain that Krik and I will ever agree upon the potential power of the PS3 compared to the 360 (I think some of his assumptions concerning the SPEs vs a full CPU core are flawed), but I do believe I understand the difficulty in programming the SPEs. I would compare it to vector programming on a Cray... very tricky to get the parallelism right, particularly considering the work performed on the PS3 has to work in real-time and there are significant barriers to avoiding race conditions, etc. Krik and I will probably just have to agree to disagree on this one... |
Crumas, I never "played" with a Cray machine but bellow is a "hello world" application for a CELL SPE. The big difference you will probably notice is the code is in C. Yes, IBM as C/C++ compilers for the PPE. They even support standard libraries. Here is the code: SPE code: --- #include int main( unsigned long spuid ) { printf("Hello, World! (From SPU:%d)n",spuid); return (0); } PPE code to load the spe code (this code actually blocks waiting for the SPE to finish but it could be loaded and run using a ppe_thread that would not block the PPE):
#include #include
int main() { unsigned int createflags = 0; unsigned int runflags = 0; unsigned int entry = SPE_DEFAULT_ENTRY; void* argp = NULL; void* envp = NULL;
spe_program_handle_t* program = spe_image_open("spu_hello"); spe_context_ptr_t spe = spe_context_create(createflags, NULL); spe_stop_info_t stop_info;
spe_program_load(spe, program); spe_context_run(spe, &entry, runflags, argp, envp, &stop_info); spe_image_close(program); spe_context_destroy(spe);
return (0); } But I agree with you that the biggest problem of using the PPEs is to fragment your data structures in such a way you can send the PPE as much data as possible (up to the 256Kb cache limit) so that the PPE can run without having to access main memory or any other I/O. This prevents racing conditions and also lock wait slowdowns maximizing the crunch power of the PPE. This is what really makes it hard. But, for example, if you send a full mesh and it's skeleton animation data to a SPE and have it deform the mesh based on the skeleton animation per vertex weights then the PPE will beat any core doing the same task. This task is basically just a loop that performs matrix multiplications on each vertex based on vertex weights in relation to each bone. I'm actually working on some C code to do this right now (as I learn PPE/SPE coding on Linux/PS3). | 
... the challenges are actually due to co-ordinating the work among separate SPEs at the application layer. Having a bunch of powerful critters able to tear through matrix transforms isn't going to do you much good if you can't keep them fed or manage to mesh what they produce as output effectively.
