Microsoft's Xbox 360, Sony's PS3 - A Hardware Discussion
by Anand Lal Shimpi & Derek Wilson on June 24, 2005 4:05 AM EST- Posted in
- GPUs
Introducing the Xbox 360's Xenon CPU
The Xenon processor was designed from the ground up to be a 3-core CPU, so unlike Cell, there are no disabled cores on the Xenon chip itself in order to improve yield. The reason for choosing 3 cores is because it provides a good balance between thread execution power and die size. According to Microsoft's partners, the sweet spot for this generation of consoles will be between 4 and 6 execution threads, which is where the 3-core CPU came from.
The chip is built on a 90nm process, much like Cell, and will run at 3.2GHz - also like Cell. All of the cores are identical to one another, and they are very similar to the PPE used in the Cell microprocessor, with a few modifications.
The focus of Microsoft's additions to the core has been in the expansion of the VMX instruction set. In particular, Microsoft now includes a single cycle dot-product instruction as a part of the VMX-128 ISA that is implemented on each core. Microsoft has stated that there is nothing stopping IBM from incorporating this support into other chips, but as of yet we have not seen anyone from the Cell camp claim support for single cycle dot-products on the PPE.
The three cores share a meager 1MB L2 cache, which should be fine for single threaded games but as developers migrate more to multi-threaded engines, this small cache will definitely become a performance limiter. With each core being able to execute two threads simultaneously, you effectively have a worst case scenario of 6 threads splitting a 1MB L2 cache. As a comparison, the current dual core Pentium 4s have a 1MB L2 cache per core and that number is only expected to rise in the future.
The most important selling point of the Xbox 360's Xenon core is the fact that all three cores are identical, and they are all general purpose microprocessors. The developer does not have to worry about multi-threading beyond the point of getting their code to be thread safe; once it is multi-threaded, it can easily be run on any of the cores. The other important thing to keep in mind here is that porting between multi-core PC platforms and the Xbox 360 will be fairly trivial. Anywhere any inline assembly is used there will obviously have to be changes, but with relatively minor code changes and some time optimizing, code portability between the PC and the Xbox 360 shouldn't be very difficult at all. For what it is worth, porting game code between the PC and the Xbox 360 will be a lot like Mac developers porting code between Mac OS X for Intel platforms and PowerPC platforms: there's an architecture switch, but the programming model doesn't change much.
The same cannot however be said for Cell and the PlayStation 3. The easiest way to port code from the Xbox 360 to the PS3 would be to run the code exclusively on the Cell's single PPE, which obviously wouldn't offer very good performance for heavily multi-threaded titles. But with a some effort, the PlayStation 3 does have a lot of potential.
Facebook
Twitter
RSS
93 Comments
View All Comments
Darkon - Friday, June 24, 2005 - link
#49WTF are you talking ?
The Cell does general-purpose processing although not as good as 360 cpu.
And Anand I suggest you do some more research on cell
Alx - Friday, June 24, 2005 - link
Someone explain to me how Sony will support 1080p please. If developers make the games run at acceptable framerate at that resolution, most people running them at 720p and 480i will be wasting at least half of PS3's rendering power.On the other hand if XBOX360 game devs make their games run just fast enough at 720p, that'll give them far more resources to work with than those poor Sony game devs.
Shinei - Friday, June 24, 2005 - link
That's not necessarily true, #48. The Cell processor doesn't do general-purpose processing, so it can't do decoding on its own--and as far as I know, even pressed DVDs have to be decoded by some kind of processor. (Of course, I know next to nothing about video equipment, so I could be wrong...)arturnow - Friday, June 24, 2005 - link
Another difference between RSX and G70 is hardware video decoder - PureVideo, i'm sure RSX doesn't need that which saves transistors countfreebst - Friday, June 24, 2005 - link
Actually, in response to 31 there is no 1080p 60 frame/sec signal. the only HD signals are 1080 30p, 24p, 60i, 720 60p, 30p, 24p.BenSkywalker - Friday, June 24, 2005 - link
Why the support for lower resolutions? I'm a bit confused by this- I can't see why anyone who isn't a fanatic loyalist wouldn't want to see the highest resolution possible supported by the consoles. The XBox(current) supports 1080i and despite the extreme rarity in which it is used- it IS used. Supporting 1080p x2 may seem like overkill, but think of the possibilities in terms of turn based RPGs or strategy games(particularly turn based) where 60FPS is very far removed from required.The most disappointing thing about the new generation of consoles is MS flipping its customers off in terms of backwards compatability. Even Nintendo came around this gen and MS comes up with some half done emulation that works on some of 'the best selling' games. Also, with their dropping production of the original XB already it appears they still have an enormous amount to learn about the console market(check out sales of the original PS after the launch of the PS2 for an example).
Warder45 - Friday, June 24, 2005 - link
errr #31 not 37Warder45 - Friday, June 24, 2005 - link
#37 is right on the money. There is a good chance that there will be no HDTV that can accept a 1080p signal by the time the PS3 comes out.It seems less like Sony future proofing the PS3 and more like Sony saying we have bigger balls then MS. Not to say MS is exempt from doing the same.
IamTHEsnake - Friday, June 24, 2005 - link
Excellent article Anand and crew.Thank you for the very informative read.
masher - Friday, June 24, 2005 - link
> "Collision detection is a big part of what is commonly> referred to as “game physics.” ..."
Sorry, collision detection is computational geometry, not physics.
> "However it is possible to structure collision detection for
> execution on the SPEs, but it would require a different
> approach to the collision detection algorithms... "
Again, untrue. You walk the tree on the PPE, whereas you do the actual intersection tests on the SPs. The SPs are also ideally suited to calculating the positions of each object (read: real physics) and updating the tree accordingly.