Official Sony PR thread

[one]

This also extends into 3D offline rendering, not just PS3 and other realtime environements. One of the goals of PS3 announced years ago was the possibility to use in-film assets directly, one example being the model and animations of Spiderman The Movie being transplanted directly into Spiderman the Computer Game. For film tie-ins these grossly reduces content creation costs of such assets - you won't have 2 separate models and mo-cap animations for film and game but can reuse the film assets.

"I approve COLLADA"

 

[Titanio]

Thanks for the explanation Shifty.

One concern for me is scalability, as a 2 million poly movie model isn't going to run too well in a game no matter what Sony might want us to believe of PS3's power! Also file formats will be astronomical as it's an XML fileformat. I think in-game content will be binary versions exported from the modeller and the COLLADA files themselves will only be used during content creation.

They seem to somewhat address that, or at least it's part of the plan. "This new standard will enable powerful content creation pipelines that can automatically condition and scale 3D geometry and texture assets for real-time playback on a wide diversity of platforms"

It's certainly a nice idea though, to consolidate all the details pertaining to a virtual model, mesh, properties, shaders, textures, into a single file..

I guess this extends to physical properties for the likes of Havok etc. now?

Also, on another note, a little snippet about Cell from this article (Cell finding new customers?):

http://www.linuxplanet.com/linuxplanet/newss/5949/1/

It's a little confusing:

Meanwhile, in an expo component of the launch, several third-party ISVs showed Linux implementations running on either ZoS or Intel platforms.

Computer Systems, Inc., for example, displayed Mercury, an Intel cluster-based medical imaging system that lets doctors perform the equivalents of virtual walk-throughs and fly-bys on CRT scans.

In the demo, Computer Systems used Microsoft Windows as the operating environment for the PC servers. But Joel Radford, VP of strategic marketing and alliances, attributed the application's fast rendering speeds to an underlying IBM Cell processor that works on Linux.

?

 

[one]

About Mercury and Cell: http://www.mc.com/cell/

 

[Titanio]

About Mercury and Cell: http://www.mc.com/cell/

Ah, thank you! Hadn't seen this before at all (I'd known about the mercury deal, but hadn't seen that on their site..I was thrown by the mention of "Computer Associates" vs Mercury).

I wonder if the answer to my windows/intel/linux/cell confusion is in there

edit - is there much in this presentation? "Using the Cell Microprocessor"

http://seminar2.techonline.com/s/mercury_jul2005

Overview:
The Cell microprocessor brings significant benefit outside the gaming market. It offers dramatically improved performance for graphic-intensive workloads and computationally intensive applications. Example targets include current and new applications in medical imaging, industrial inspection, aerospace and defense, seismic processing, and telecommunications.
This webcast will overview the Cell architecture. In addition we will provide simple program examples to illustrate key Cell development tools. We will contrast the Cell's SPU instruction set with the older PowerPC Altivec (r) extensions (which are also found inside Cell). We will talk at a high level about the benefits that Cell brings to a few specific applications that are graphic or computationally intensive.

Looks like it could be interesting..

 

[Titanio]

Was indeed pretty interesting - no earthshattering news or new detail - they kept teasing about having code walkthroughs etc. ready, but they pulled them at the last minute because the audience didn't seem to be geared toward that. But there were interesting general comments anyway.

Some slides and interesting bits (long, but interesting):

But this is a kind of example of why we feel that there's a need for technologies like Cell in the markets we serve. It gets these algorithms to market sooner.

And so what we've come to say after looking at a bunch of applications is we think that performance per watt gains -- now performance by itself is important to some applications, but this is sort of a multicomputer in a chip, and as a result you're already kind of parallelizing applications and so the raw performance of the chip is interesting, but the more important factor in most of our markets is the performance per something. Per dollar in some commercial markets. Per watt, which kind of also translates to per cubic inch because you got to get that wattage out in other markets. And so three to four times we think better in performance per watt, floating point performance per watt. In general markets that we're looking at against technologies in that same timeframe, just to give you a rough idea. But the reality is it's going to vary much wider than that when you actually look at particular customer requirements.

You can see that you can put a lot more SPUs down in the same space as you can put down PowerPCs. So if for some applications the SPU is as fast as a PowerPC, maybe even faster, you can get more of them down because of the nature of just the basic size of these two things. So this shows an example of one of the reasons a Cell can be faster. It's because the designers have the ability to make a tradeoff like this one.

A single SPU can host about a 4k FFT out of local memory. Where the whole FFT is the program, the code, everything you need is in local memory. And so the way to compare that to is to a PowerPC's L1 cache. Because the performance of the SPU local memory is like a very large L1 cache on a PowerPC. And a PowerPC's L1 cache can really only host about a 2k FFT. So from one perspective we have a lot more memory available, at least really fast memory. From another perspective is if you need an FFT that's more than 4k you have to start doing a lot more staging of data in order to pull it off.

So the middleware that we've created for this kind of thing and that we're moving forward for Cell is based on a standard -- well, it's one of these standards that's not an IEEE standard, just a bunch of companies have a website and use the same standard, and it's called DRI, Data Reorganization Interface. The website's on here, data-re.org. Our implementation is called PAS-DRI. PAS stands for Parallel Application System. And this is the middleware that we use to try to actually make the job of programming things like a Cell and very soon a Cell approachable. We allow customers to use it. It's one of our products. We use it ourselves. It's how we move forward here.

Will this be available/useful generally? For game devs?

There are applications that are absolutely perfect for a DSP chip. There are applications that are perfect for a graphics processing unit. In fact we announced a strategic relationship with NVIDIA around graphics processor units, I think it was about a year before the Cell announcement occurred. And then there are applications where traditional PowerPC chips are great. So we intend to continue to use the right technologies to match the applications that our customers have. And so Cell is in our portfolio.We do think that Cell will be used a little more often than some of the other things. But we're by no means walking away from under the other things.

So someone's asking about Cell on fixed point datasets and what performance analysis has been performed. We have been doing fixed point convolutions. Specifically we've been looking very carefully at nine by nine fixed point convolutions. In one of our markets. That is we actually don't use that algorithm but it's an interesting algorithm. Cell is less compelling for fixed point than floating point because it really is optimized for floating point. But at the same time the end of that fixed point exercise was that Cell was the right technology for that particular market. It just was the difference between Cell and the alternatives wasn't as big as it was in the markets that were floating point-oriented.

Does it support multithreading? You can do multithreading, yes, but there is an astounding amount of state inside an SPU. So the idea of context switching in SPU is something that Mercury will likely encourage customers not to do. Just because of the amount of state, 128 vector registers is an astronomical amount of state to throw on the stack and pull off the stack whenever you switch between threads. But the model certainly supports it.

Do do you think -- so someone's asking if I think that the external memory bandwidth of Cell is sufficient to keep all eight SPUs busy. Yes. The applications that we've mapped today we've been able to actually find algorithms where the memory bandwidth is not the deciding factor. There's an awful lot of bandwidth between the RAM bus chips and the Cell processor itself.

So we can expect some news from Mercury at Siggraph? That's two bits to keep an eye on - the Saarcor raytracing and now this.

edit - according to this: http://www.openrt.de/siggraph05.php, it may be Mercury that's hosting the cell-based raytracing demos..

There's a full transcript available, but unfortunately I can't get the link out of the page the webcast is one. If I could upload it to somewhere I would, and link it here, or you can check it out yourselves at the link in the last post.

Don't know if this is the right thread for this kind of stuff or what..I'd gladly put it in its own if necessary

 

[blakjedi]

oes it support multithreading? You can do multithreading, yes, but there is an astounding amount of state inside an SPU. So the idea of context switching in SPU is something that Mercury will likely encourage customers not to do. Just because of the amount of state, 128 vector registers is an astronomical amount of state to throw on the stack and pull off the stack whenever you switch between threads. But the model certainly supports it.

That sounds alot like the special sauce in the Xenon's VMX units... ho hum...

 

[Titanio]

That sounds alot like the special sauce in the Xenon's VMX units... ho hum...

It's been known for a while that the SPUs have 128 registers. Unknown if the VMX on the PPE has that, although there's been some speculation recently that the second revision of Cell does.

Also, Mercury is the one demonstrating ray-tracing on Cell afterall. I guess they worked with IBM and IBM worked with the University of Saarland on it. It'll be at their booth from tomorrow:

http://www.mc.com/mediacenter/events/event_details.cfm?EventID=209

In partnership with IBM and other key partners, Mercury is demonstrating advanced 3D visualization solutions for challenging applications that require the utmost in image clarity and performance. Of particular interest is Mercury’s demonstration of breakthrough ray tracing software on Cell technology.

This is turning into more of a Mercury/IBM PR thread, but heh

 

[mckmas8808]

Really interesting news you found there. Good find Titanio. Keep us posted with an update.

 

[Carl B]

Titanio great finds. It's pretty impressive how many events there are these days featuring Cell in one form or another; must be at least one a month at present. We should do a better job of keeping track.

Mercury Systems in particular really seems to have 'found religion' with this thing.

That being said though, I think this definitely would have been worthy of it's own thread - really doesn't seem limited to 'Sony PR' in the least.

 

[version]

"it support multithreading? You can do multithreading, yes, but there is an astounding amount of state inside an SPU. So the idea of context switching in SPU is something that Mercury will likely encourage customers not to do. Just because of the amount of state, 128 vector registers is an astronomical amount of state to throw on the stack and pull off the stack whenever you switch between threads. But the model certainly supports it. "

multitheading with softwarecache on spe equal general purpose code
solvable without stack .....