Challenging the Playstation 2

In part 2 of this series we'll focus on Nintendo's GameCube but for now it's time to talk about how the hardware stacks up to the Playstation 2, the current hardware champ in the console market.

PS2 vs. Xbox: CPUs

Let's start off with host CPUs; the PS2 is driven by what Sony likes to call their Emotion Engine.  The Emotion Engine (EE) is a 128-bit MIPS processor that operates at 300MHz.  The idea of the EE being a 128-bit processor came about because it features 128-bit general purpose and SIMD registers as well as dual 64-bit integer units.  The MIPS ISA gives the EE a bit of an advantage from the standpoint of having more general purpose registers (GPRs) and not having to undergo any significant decoding stages just to reduce instructions to more manageable RISC operations. 

Sony also claims that the EE has a dedicated MPEG-2 decoding block which should help in DVD playback however this is offset by the hardware motion compensation features of the NV2A GPU in the Xbox and shouldn't be blown out of proportion as a feature.

The biggest issue with the EE is that it has a very small on-die cache and relies on having a very high-speed memory bus, more on that later though.  A 16KB instruction cache is more than enough for the processor however the 32KB data cache leaves much to be desired.  During its design phase the idea of having a fast 3.2GB/s bus to main memory may have been impressive but you are all very aware of how important a fast, high-bandwidth L2 cache is to performance. 

The true power of the EE comes from its two vector units which are known as VU0 and VU1.  These are referred to by Sony as two additional floating point units and aid the basic FPU in 3D T&L calculations.  The power provided by these vector units is tremendous however their downfall is in their implementation.  The power of the two VUs exists in the proper use of them as serial counterparts in handling the T&L calculations necessary during 3D rendering, but with the PS2 being relatively new architecture and dramatically different from what most developers had seen in the past, getting the most out of the host CPU was quite difficult.  This is where the majority of the learning curve for developers came from when dealing with the PS2, especially considering that the PS2 shipped to developers without any C libraries.  Writing assembly to control the interaction between these two units and the rest of the CPU is not an easy task to say the least and led to many frustrated PS2 developers.  Internally to the CPU, the VUs and the rest of the CPU are connected by 128-bit pathways meaning that moving data around the CPU from VU to VU isn't done as easily as possible. 

The Xbox host CPU however is the very well known Coppermine derived core which although has the unfortunate limitations of the x86 ISA, also carries the benefits of being a very well known architecture with much ISV support.  The processor runs at a higher clock rate than the EE but we all know the meaninglessness of clock rate as a single performance metric.  What is important to note is the 128KB L2 cache with a 256-bit data bus comes in quite handy in keeping the execution units of the processor busy and even more important is that the CPU does not have to handle any of the T&L calculations.  If games are written properly the host CPU should only be used for AI, physics and other such calculations, leaving the GPU to handle all of the T&L and actual 3D rendering.  Removing developers from the mindset of the host CPU handling T&L has apparently proved somewhat difficult but the better looking games are testament to the potential of the Xbox GPU when utilized properly. 

Disassembling the Unit PS2 vs. Xbox: Graphics Processors


View All Comments

  • Anonymous User - Monday, October 6, 2003 - link

    Awesome, informative article. The author did an excellent job of researching the platforms. Keep up the good work! Reply

Log in

Don't have an account? Sign up now