Live data from Hacker News

PlayStation 3 Architecture (2021)

copetti.org

41–50 of 63 posts

Re: PlayStation 3 Architecture (2021)

#43

PS3 would have done better as a gaming console if the architecture wasn't so hard to program and wasn't forced to be a trojan blue-ray player.

IIRC the Cell architecture was OK-ish for a CPU architecture, just that the PS3 was too gimped on RAM(256MB) for game devs to use to its full potential. The trojan Blu-ray Player actually worked in its favor.

The big issue with the Cell architecture is that it was designed to act as a GPU as well which they realized later in development that it won't be powerful enough for those graphics and they'll still need a dedicated GPU in addition. That's why the Cell is such a franken-cpu compared to the vanilla IBM PowerPC it's based on.

The Cell architecture was also a product of it's time. In the early 00s when they started Cell development nobody would have expected that X86 would have made such leaps by the time the PS3 hit the market.

Re: PlayStation 3 Architecture (2021)

#44
post #34
post #23

i did a bit dev on ps3 and i remember there was a small memory on the chip, like 256k that was accessible to programmer. i always found this very appealing, having a blazing fast memory under programmer control so i wonder: why don't we have that on other cpus?

We call it "cache" don't we these days? And they've become massive - Apple M series and AMX Strix series have 24/32MB of L3 cache. This is where a lot of their performance comes from.

Is the cache on M series and Strix under control of the programmer? I was under the impression those were traditional caches and thus automatically handled by the hardware.

Re: PlayStation 3 Architecture (2021)

#45
post #25
post #21

Earlier quoted context omitted.

That would be the PS2’s VUs which had an upper and lower pipe and it was easier to write instructions for each in separate columns. Then in one SDK we received program called vcl which took a single list of instructions, doing all the pipelining for you, as well as optimizing loops and assigning registers automatically. It was a godsend.

I can't remember the details because we coded the SPU in C, but the PS3 SPUs had odd and even cycles with different access properties too.

Discussed in the article, should you want a refresher. https://www.copetti.org/writings/consoles/playstation-3#arch...

Re: PlayStation 3 Architecture (2021)

#46
post #23

i did a bit dev on ps3 and i remember there was a small memory on the chip, like 256k that was accessible to programmer. i always found this very appealing, having a blazing fast memory under programmer control so i wonder: why don't we have that on other cpus?

This is the SPU's local store. It's mentioned in the article. More details at https://en.wikipedia.org/wiki/Cell_(processor) Apparently it could in theory go to 4GiB.

"The local store does not operate like a conventional CPU cache since it is neither transparent to software nor does it contain hardware structures that predict which data to load."

I think the general term for this is scratchpad memory. https://en.wikipedia.org/wiki/Scratchpad_memory

This kind of indicates the problem with it. When switching tasks, each local store would have to be put into main RAM and the new task's local stores pulled back out. This would make switching tasks increasingly expensive. I believe the PS3 (and maybe all cell processors) dealt with this by not having tasks switch on the SPUs.

Re: PlayStation 3 Architecture (2021)

#47
The PS3 was the only console I had in my life. I bought it specifically to play the original Demon Souls.

I see a lot of comments here saying how underwhelming it was. And that’s probably true.

But one thing always surprised me. The quality of the games for PS3 at the platform end of life were gorgeous. Developers became so good at extracting all the power from the platform (and it had some in its difficult to use way), that great things were achieved.

Re: PlayStation 3 Architecture (2021)

#49
post #23

i did a bit dev on ps3 and i remember there was a small memory on the chip, like 256k that was accessible to programmer. i always found this very appealing, having a blazing fast memory under programmer control so i wonder: why don't we have that on other cpus?

> why don't we have that on other cpus? We do, it's called "cache" or "registers".

It's definitely not registers; the SPEs had 128 128-bit registers each.

In some ways it's like cache, it has the latency of L1 cache (6 cycles), but it's fully deterministic in terms of access.

Post reply on HN