256K is only a 90x90x32bpp texture...

@ CrashMan

Textures will reside in main / graphics RAM not on the SPE's local memory store or a PC / XBox 360's CPU cache, 7.1 audio also takes up lots of data, but here we're talking about executable code. 256KB equals hundreds of pages of code, a lot of code for a programmer to write!

You're talking about executable code size.  I don't think anyone is disputing that 256 kB is enough for the executable code, but you have to store both the code and your working set of data in that 256 kB.  And weren't you trying to convince me that it was a good idea to do pixel shading on the SPEs?  I would think textures would be handy if you're going to run pixel shaders.

@ Entroper

I think this may enlighten you:

"The key to running any algorithm on the SPEs is to develop
a streaming formulation in which data can be moved
through the processor in blocks. We move eye data in
scanline order and double buffer the scanline input. While
one scanline of pixels is being processed we prefetch the
next scanline. As each scanline is completed it is written to
the shadow texture. We have measured the DMA waiting
for the scanline data and it was negligible."

"Each SPE computes a set of scanlines for the shadow
texture. They deliver their result directly into GPU
memory in order to minimize the final render time."

http://research.scea.com/ps3_deferred_shading.pdf

@ Entroper

You haven't answered my questions above. I would love to know your perspectives and do you think Killzone 2's Deferred Rendering techniques holds potential? (the most impressive lighting, animation and effects I have so far seen in a FPS game so far, the project is our Dutch pride )

Anyway IMO it certainly didn't look CrashMan understood the issue, how would you have responded instead?

---
Anyway just to show what you can do with just a little piece of code, an old friend wrote some excellent programming languages including the highly acclaimed AmigaE programming language, I hooked him up for an interview with my oldtime fellow OSNews editor (she was such a big fan of programming BeOS apps she married a former BeOS coder. , very nice people when I visited them in Silicon Valley a couple of years go) for an interview (easy code example included, just for intended some readers to understand what program code can look like):

http://osnews.com/story.php/169/Interview-Wouter-van-Oortmerssen-on-SHEEP

MikeB said: @ Entroper And weren't you trying to convince me that it was a good idea to do pixel shading on the SPEs? I think this may enlighten you: "The key to running any algorithm on the SPEs is to develop a streaming formulation in which data can be moved through the processor in blocks. We move eye data in scanline order and double buffer the scanline input. While one scanline of pixels is being processed we prefetch the next scanline. As each scanline is completed it is written to the shadow texture. We have measured the DMA waiting for the scanline data and it was negligible." "Each SPE computes a set of scanlines for the shadow texture. They deliver their result directly into GPU memory in order to minimize the final render time." http://research.scea.com/ps3_deferred_shading.pdf

We've discussed that article before, and I know about data streaming (how do you think I coded a matrix multiply?).  My point was that you keep trying to have it both ways on every issue, or jump from topic to topic to topic.  This thread, like the others, has grown tiresome.

My position on deferred rendering is that I wish developers would find something more creative to do with the SPEs.  The GPU is better at filling pixels -- use the SPEs to do something new.

@ Entroper

It's not like you wouldn't use the GPU, the Cell and RSX go hand in hand, each offering their strong points with the SPEs performing both GPU and CPU related tasks. Writing the ideal game engine for this architecture from scratch (White Engine) or fully adapting legacy game engines (Insomniac's engine) takes time and effort.

What kind of "new" things would you be thinking about what hasn't being been experimented with already? Currently it's all about doing things faster, smarter and doing more at the same time than was possible before.

So have you played Ratchet & Clank: Tools of Destruction and Uncharted? What is your opinion with regard Killzone 2's lighting?

well 256K of code is pretty useless with no data. Again my point that this stuff would need to be externally accessed, destroying the best case scenario.

Accessing external ram HAS to be slower than the built in memory, otherwise there would be no point of the built in, so even with memory streaming, any external memory read/write will slow the thread down.

@ CrashMan

That's why its not good to have a shared bus for the GPU/CPU like on the XBox 360, that's why the fast low latency XDR RAM is important to the Cell, that's why the Cell has a huge internal bandwidth!

Testing and practical uses like in Killzone 2 have so far been very promising, much faster than you can achieve with other CPUs in many cases. The Cell is designed for flexible and powerful stream processing.