Playstation 3 Gathering Components

briancnorton writes "Cnet has a story about how Sony has licensed some Rambus connection technology for the playstation 3. One technology is for chip-to-chip communications and the other for chip-to-RAM at over 100 Gbps. These are all parts of the 'Cell' processor system that is supposed to do over '1 trillion mathematical calculations per second.'"

Comments

Some Specs

[robbyjo]

Can be found here.

Re:Rambus?

[dreamchaser]

You've got it backwards actually. Servers tend to have lots of random access, so they need low latency. Modern games tend to stream a lot of data, so bandwidth becomes more important. There is a reason why the P4/RDRAM combo excelled at Quake 3 Arena; oodles of bandwidth.

Streaming applications: bandwidth is the most important
Apps with lots of random memory access: latency is far more important.

Re:1 Trillion calcs/sec for 640x480

[martyn s]

Gamecube does NOT support 720p or 1080i. It supports 480p, which takes no more processing power than 480i since 480i is really rendered in 480p with half the pixels being thrown out.

Xbox, in theory, supports 720p and 1080i, but most games don't support it. Unless it's rendering simple geometry, 720p and certainly 1080i is just way beyond what the Xbox can handle.

Re:1 trillion ips

[Gizzmonic]

The PS2's video hardware "much" superior to the Dreamcast? What video hardware? The PS2 has no dedicated VRAM, which means:

1)Limited amounts of color can be loaded at one time...every notice how bland the color is in most PS2 games? Many look like Quake 1, studded in brown, green, and grey.

2)Not too many textures can be loaded at once. Most PS2 games have chunky, flat textures.

Also, the PS2 can't do antialiasing without a huge performance hit, so lots of games "cheat" by blurring. And boy, does that ever get annoying when playing redeyed into the wee hours...

The PS2 in general is more powerful than the Dreamcast, I won't debate that. It seems to have be designed to act as a node for a huge parallel computer (why this was done for a game console is anyone's guess).

But in terms of texture quality, color depth, etc, the Dreamcast wins out. Take a look at Phantasy Star Online; the graphics there beat any PS2 game out there. PS2 graphics are chunky, dull, and blurry, with few exceptions.

Backward compatability with PS2 is unlikely

[Xeger]

Few people know it, but the PS2 is only backward-compatible with the PS1 due to a happy accident. As I understand it, the PS2 uses a PS1 CPU for its I/O and sound processing. When you pop a PS1 game into the system, the PS2 BIOS switches control of all the peripherals over to the PS1 CPU and busies itself emulating the PS1 graphics subsystem.

With the radical changes inherent in a cell design (as nebulously defined as the term is right now), I can't see how they could pull off the same trick twice. In theory, if they managed to do a full software emulation of PS2, they'd get free PS1 support.

Re:What I want to know... (ease of programming)

[entrager]

The PS2 still is hard to program for. The difference is that now there are some libraries that can be used to simplify things. In the beginning everyone was forced to do things in pure assembly (OK, ALMOST pure assembly). But now the companies that have been working on PS2 games for years have developed libraries and engines that are already optimized. Haven't you noticed that most games that come out of the same development studio have the same look and feel? Of course each game is a bit more refined, but overall stageringly similar.

It seems to be a common misconception that the PS2 has multiple CPUs. It doesn't. What it does have is a single CPU that is split up into several independantly operating units. The dual-CPU idea developed from the fact that the Emotion Engine has two vector processing units that operate almost exactly the same. These two units make up the bulk of the mathematical processing in the PS2, and must be coded separately.

All of the code I've written for them has been in assembly and the process is GRUELING. Each unit actually performs two operations at once, a lower and upper instruction. Since the ultimate goal is optimization you end up writting all your assembly and then rearranging everything so that the combination of upper and lower instructions don't step on top of each other and everything runs without any wasted clock cycles. I have heard of a few tools that have been developed to compile C into optimized VPU code, but I haven't used any and I doubt they work very well. A good camera manipulation program will only take maybe a hundred lines of assembly if it's optimized correctly, but I bet these programs spit out many many more.

(Wow, I really steered off the original topic didn't I?)

Re:Wait A Second..

[Midnight Thunder]

If you read the article, this issue is brought up (last three paragraphs):

With product sales and licensing fees in jeopardy, Rambus launched into its second life, as a litigant. Starting in 2000, the company began to seek patent royalties and pursue lawsuits against Micron, Infineon and other memory companies. The company said that patents it filed in 1990 entitled it to royalty payments on all of the SDRAM and DDR DRAM ever sold.

Potentially, the lawsuits could have entitled the company to billions in royalties. Infineon and others, however, alleged that Rambus committed fraud in securing those patents and, so far, the memory companies have won in court.

Since then, the company has tried to position itself as the kindler, gentler Rambus, with executives stating that the company will work more on chip connections and spend less time in court.

So it looks like that they have realised that litigation was not getting them anywhere and decided to go back to their core business.