The definitive console specs thread.

[PeterT]

The Wii bandwidth column should be 4GB/s / 3.9GB/s.
(ie. 7.9 total - it currently says 4)

[edit]
Oh, and the bandwidth for the 3MB embedded 1T-SRAM is probably 15.6GB/s. (Extrapolated from the previous value and the GPU clock increase)

At least the processing capability / bandwidth ratio does not seem so bad on Wii. Also, very good external bandwidth compared to previous gen. Not counting XBox's 6.4 GB fully of course because it had to use it for the framebuffer r/w.

[edit2]
Another thing, as I appreciate the effort of at least trying to make an accurate spec chart:
Why did you list stuff like the register size for the CPUs, but not some of the other - arguably more important - metrics, like L1/L2 cache size, or number of execution units? I believe that for a theoretical overview perhaps even adding peak FLOPS may be helpful, but I'm sure there are some people that disagree on that.
Anyway, please keep this up, it would be nice to have a single corrrect resource to point to for basic console specs.

 

[StefanS]

The Wii bandwidth column should be 4GB/s / 3.9GB/s.
(ie. 7.9 total - it currently says 4)

I think Neeyik means about 4 GB/s each. It's just a more compact notation instead of 4 ? / 3.9?.

 

[Neeyik]

Hup - actually I just didn't know the SDRAM bandwidth!

PeterT - ta for those figures. As for why I chose those particular figures for the CPUs listed...err, no idea. It's been so long since I started doing the charts that I can't remember why I just used those, although I suspect it's because of the old "16 bit vs 32 bit vs 64 bit" arguments in the past. I also think I wanted to keep the details purposely brief because it would mean for a lot of consoles lots of blank entries due to the lack of concrete public information.

 

[Shogmaster]

If you count the peak transform rate it should be :
-66 millions on the PS2
-32.4 millions on the GameCube (5 cycles@162MHz)
-116.5 millions on the Xbox (2 cycles@233MHz)

On the PS3 you're counting the peak transform rate (1Gpoly/s) but on the Xbox 360 you're counting the setup rate (0.5GPoly/s).

This is what I noticed at first sight

Yep. And ideally, you should have seperate numbers for transforms and setup/draw. For 360 and PS3, this should be easy enough since we already know Xenos' setup rate, and some PS3 devs have dropped clues to RSX's setup rate (1 triangle every 2 cycles).

Also, you should just replace 250nm with a "?" for Saturn and PSX chips' fab numbers. That's just too far off, even for speculation.

 

[Graham]

Very surprised (and happy) to see Xenos can do 32bit depth.

mwahaha

*plans for world domination*

 

[Fafalada]

And ideally, you should have seperate numbers for transforms and setup/draw

In machines that don't have fixed T&L - "transform" is just another way of stating programmable flops (Eg, which do you prefer, 400GFlops or 12GVert/s?).
Setup is more iffy since it consists of different operations on each platform (with some others being decoupled, or requiring programmable resources to perform them).

I think I'll mark those values that are known to be peak transform rate accordingly.

In that case I would count those as I described above - programmable FLOPs/32 (give or take). Also on that note - DS peak transform IIRC is 4MVert/s (yes, draw rate really is that much lower).
Perhaps it would make more sense to not list system transform rate under GPU either? (since some of the chips listed relied on other processors to perform transforms).

Btw, in regards to register sizes -
Dreamcast and PSP FP SIMD can both use register access in 32/128/512bit quantities. On PSP there's more to this, but I'm not sure how this could be fit into a simple chart.
Not just pointing this out to confuse numbers btw - I think it merits a note mostly because IBM stuff in PS3/360 is more primitive in that respect (in a sense it's not unlike the P3 having the OOOe advantage).

 

[ihamoitc2005]

If you count the peak transform rate it should be :
-66 millions on the PS2
-32.4 millions on the GameCube (5 cycles@162MHz)
-116.5 millions on the Xbox (2 cycles@233MHz)

On the PS3 you're counting the peak transform rate (1Gpoly/s) but on the Xbox 360 you're counting the setup rate (0.5GPoly/s).

This is what I noticed at first sight

Hello. Small suggestion below for clearness of peak numbers but not real performance.

-150 millions on the PS2 (2x4cycles@300mhz)
-32.4 millions on the GameCube (5 cycles@162mhz) (peak?)
-116.5 millions on the Xbox (2x4cycles@233mhz)

 

[Panajev2001a]

Hello. Small suggestion below for clearness of peak numbers but not real performance.

-150 millions on the PS2 (2x4cycles@300mhz)
-32.4 millions on the GameCube (5 cycles@162mhz) (peak?)
-116.5 millions on the Xbox (2x4cycles@233mhz)

4 Cycle perspective transform on VU0 ? Whoa, even on VU1 with dual FDIV's the performance was stuck to 5 cycles .

IIRC, VU0's perspective corrected vertex transform (object, view, camera transform and divide by w) could take a minimum of 7 cycles (limited by FDIV's performance) while on VU1, since it had two FDIV's, you could get down to a minimum of 5 cycles.

 

[Lazy8s]

The 7 million polygon/sec peak rate for Dreamcast is the CLX2's set-up limit (and the number really is right at 7 million and therefore wouldn't need the "~" qualifier. The chip's Z-buffer depth is only near 32-bit floating-point, though, and therefore could use the "~".)

 

[Neeyik]

Yep. And ideally, you should have seperate numbers for transforms and setup/draw. For 360 and PS3, this should be easy enough since we already know Xenos' setup rate, and some PS3 devs have dropped clues to RSX's setup rate (1 triangle every 2 cycles).

Easy enough for newer hardware but unless somebody has concrete facts for the others, there would be too many blanks. I'd be happy to do it if we could get the numbers though.

Also, you should just replace 250nm with a "?" for Saturn and PSX chips' fab numbers. That's just too far off, even for speculation.

To be honest, they weren't speculation if I remember correctly when I originally sourced the figures (from a variety of references) but I suspect, in hindsight, that the figures were just incorrect back then.

In that case I would count those as I described above - programmable FLOPs/32 (give or take). Also on that note - DS peak transform IIRC is 4MVert/s (yes, draw rate really is that much lower).
Perhaps it would make more sense to not list system transform rate under GPU either? (since some of the chips listed relied on other processors to perform transforms).

Good points - I'll move the throughput figures into a separate section, in a similar manner as to how I do the GPU charts.

Btw, in regards to register sizes -
Dreamcast and PSP FP SIMD can both use register access in 32/128/512bit quantities. On PSP there's more to this, but I'm not sure how this could be fit into a simple chart.
Not just pointing this out to confuse numbers btw - I think it merits a note mostly because IBM stuff in PS3/360 is more primitive in that respect (in a sense it's not unlike the P3 having the OOOe advantage).

Hmm, I think I'll need to add additional notes to explain this. What I wanted the figures to show was the size of the actual registers and not values where units can combine registers for larger values, but if I could clarify the former for each CPU, I can then add the appropriate note to explain the point you're making.

The 7 million polygon/sec peak rate for Dreamcast is the CLX2's set-up limit (and the number really is right at 7 million and therefore wouldn't need the "~" qualifier. The chip's Z-buffer depth is only near 32-bit floating-point, though, and therefore could use the "~".)

Thanks for the further clarification - I'll address this later on.

As a general note to everyone, it's this type of feedback and discussions that I've always hoped would lead to the chart being as "correct" as possible but, in all honesty, I've never really given that section as much attention as it really deserves. It's perhaps time that I did (I could expand the CPU sections for a start) but the problem is that I'm not much of a console person, so my will power for research tends to drop off quite quickly!

 

[Panajev2001a]

Easy enough for newer hardware but unless somebody has concrete facts for the others, there would be too many blanks. I'd be happy to do it if we could get the numbers though.

Peak theoretical transform rate for the Emotion Engine could be calculated as follows:

Peak VU0 + Peak VU1 + Peak R5900i ~= 300 MHz / 7 cycles + 300 MHz / 5 cycle + 300 MHz / ~20-28 cycles = (42.8 + 60 + 15-10.7) MVertices/s, that is 102.8 MVertices/s for the two VU's alone.

 

[swaaye]

Neeyik:

Regarding N64, I'm sure it couldn't do 1 pixel per clock. Probably half that. Kinda like Rendition V1000. And I recall ERP saying that if they used Z-buffering, fillrate got chopped in two. N64's GPU was called the "Reality Co-Processor" (RCP).

Might want to mention N64's RAM expansion to 8MB. Many later games used it so it was probably rather popular.

On Xbox, I see a S-code listed as codename. I kinda doubt all the CPUs were the same S-Code. Undoubtedly the codename should be Coppermine. Or Celermine.

Saturn processors woulda been manufactured at 500 nm I believe. Like early P5 and most 486s. It had twin CPUs so that needs to be mentioned. In fact, Saturn had lots of processors for graphics too. And a little 68000 for audio. It was kind of a mess.

 

[ihamoitc2005]

Not perspective correct

4 Cycle perspective transform on VU0 ? Whoa, even on VU1 with dual FDIV's the performance was stuck to 5 cycles .

IIRC, VU0's perspective corrected vertex transform (object, view, camera transform and divide by w) could take a minimum of 7 cycles (limited by FDIV's performance) while on VU1, since it had two FDIV's, you could get down to a minimum of 5 cycles.

Hello my friend. I only talk of not perspective correct vertext transform. This is 4 cycles no? Also what is Xbox performance for perspective correct vertex transform?

 

[Panajev2001a]

Also what is Xbox performance for perspective correct vertex transform?

Hello .

IIRC, each of NV2A's VS ALU's take 4 cycles to do a perspective transform, so it makes sense we use perspective transform rates IMHO.

 

[Panajev2001a]

Neeyik:

Regarding N64, I'm sure it couldn't do 1 pixel per clock. Probably half that. Kinda like Rendition V1000. And I recall ERP saying that if they used Z-buffering, fillrate got chopped in two. N64's GPU was called the "Reality Co-Processor" (RCP).

Which in turn.... RCP = RSP (Reality Signal Processor, Fixed-Point vector processor... T&L, clipping, culling, triangle set-up, etc...) + RDP (Reality Display Processor... rasterization, texturing, etc...).

 

[Zeross]

Saturn processors woulda been manufactured at 500 nm I believe. Like early P5 and most 486s. It had twin CPUs so that needs to be mentioned. In fact, Saturn had lots of processors for graphics too. And a little 68000 for audio. It was kind of a mess.

You bet it was
-2 SH2 : one master, one slave
-1 SH1 : used as the CD-ROM drive controler
-a bus controler with a DMA engine including a DSP in it
-VDP1 : for polygons and sprites
-VDP2 : for backgrounds and display
-68EC00 but i don't remember what it was used for
-SCSP : a sound DSP

 

[reltham]

On your chart in the link of the second post in this thread.

The PS3 FrameBuffer bandwidth number of 22.4GB/s was based on the memory clock being 700Mhz, but didn't it end up being 650Mhz in released hardware, so the number should be around 20.8GB/s.

 

[StefanS]

From Shifty's post here

EDIT: sorry Shifty.

 

[Paul_G]

From Shity's post here

Don't let Shifty see you call him that

 

[reltham]

That chart is based on the 700Mhz clock rate. 128bit memory width x 700Mhz (1400Mhz effective) = 22.4Gb/s.

It's been said on several sites that the final clock rate ended up at 650Mhz for the GDDR memory on the PS3. Which would be 128 x 650 x 2 = 20.8Gb/s.