GT4 vs Forza [Let the battle begin]
- Thread starter Front
- 5,710 comments
- 309,274 views
- 1,620
Monton, your looking at it from a way too technial & idealistic point of view. Yes if we're talking about polys only your right, you can pump double when the framerate is halved. However this is assuming zero other bottlenecks in the system (something you kind of admitted). When physics, AI, RAM limit, etc is taken into account there will always be a pronounced curve to the relationship. I was only ever talking about fps/graphical impressiveness, which includes how a human percieves the graphics to be better/worse depending on the GENERAL look of the game! I was never talking dryly about the fps/polys relationship, which is different, but still affected by a curve in ANY real world game application where the limits of the system are trying to be pushed, and other bottlenecks arise, like on any home console.
If people want to misunderstand what I have said then by all means go ahead. Gek is right, also Monton is right if we're talking 1st year computer science concepts. I'm not having a go at him though - he just thought I was talking about a completely different hypothetical situation regarding fps/polys where there are no other limiting factors. I was just talking about the fps/how cool we think the graphics are!
Eg Forza has many more polys in its car models than GT4's 5000, however how we percieve the look of the cars is certainly not a linear relationship!!! Yes there's lighting, and artistic issues impacting as well, but my point was "half the fps, the game can't look even nearly twice as good". How we percieve graphics is subjective anyhow!
Also, someone said I was too obvious and just go well "duh"... perhaps your not the person I wrote the real obvious stuff for... your smart, but also a smartarse!!
My advice: pick some nits when there's some nits to pick...
If people want to misunderstand what I have said then by all means go ahead. Gek is right, also Monton is right if we're talking 1st year computer science concepts. I'm not having a go at him though - he just thought I was talking about a completely different hypothetical situation regarding fps/polys where there are no other limiting factors. I was just talking about the fps/how cool we think the graphics are!
Eg Forza has many more polys in its car models than GT4's 5000, however how we percieve the look of the cars is certainly not a linear relationship!!! Yes there's lighting, and artistic issues impacting as well, but my point was "half the fps, the game can't look even nearly twice as good". How we percieve graphics is subjective anyhow!
Also, someone said I was too obvious and just go well "duh"... perhaps your not the person I wrote the real obvious stuff for... your smart, but also a smartarse!!
My advice: pick some nits when there's some nits to pick...
- 13
- LordOfDaNurburg
James2097Monton, your looking at it from a way too technial & idealistic point of view. Yes if we're talking about polys only your right, you can pump double when the framerate is halved. However this is assuming zero other bottlenecks in the system (something you kind of admitted). When physics, AI, RAM limit, etc is taken into account there will always be a pronounced curve to the relationship. I was only ever talking about fps/graphical impressiveness, which includes how a human percieves the graphics to be better/worse depending on the GENERAL look of the game! I was never talking dryly about the fps/polys relationship, which is different, but still affected by a curve in ANY real world game application where the limits of the system are trying to be pushed, and other bottlenecks arise, like on any home console.
If people want to misunderstand what I have said then by all means go ahead. Gek is right, also Monton is right if we're talking 1st year computer science concepts. I'm not having a go at him though - he just thought I was talking about a completely different hypothetical situation regarding fps/polys where there are no other limiting factors. I was just talking about the fps/how cool we think the graphics are!
Eg Forza has many more polys in its car models than GT4's 5000, however how we percieve the look of the cars is certainly not a linear relationship!!! Yes there's lighting, and artistic issues impacting as well, but my point was "half the fps, the game can't look even nearly twice as good". How we percieve graphics is subjective anyhow!
Also, someone said I was too obvious and just go well "duh"... perhaps your not the person I wrote the real obvious stuff for... your smart, but also a smartarse!!
My advice: pick some nits when there's some nits to pick...
Well, James. I really thint that, at the end of the day, we agree in almost every aspect.
I know that there are bottlenecks (mainly the ram bottleneck) that affect this calculation. I always said "roughly twice" and "as a rule of thumb". And I mentioned the ram bottleneck before: no matter how many polygons you can draw if you don't have the memory to draw them.
What i wanted to make clear is that to suggest that half the framerate means 10% or 25% or even 50% more polygons is false. The real number is much nearer 100%. That is, the ratio is *roughly* linear.
Another example (this time counting the physics also): If in one second your engine can fully draw (that is, put on screen, including physics) two cars, it's evident that in two seconds it should be able to draw four cars. The physics example is even more clear, because its mainly pure math (processor power, with little memory impact): If you can make the *calculations* for one car in one second then you can do the calculations for two cars in two seconds.
Yes, I know I'm almost repeating myself...
And, of course, I absolutely agree with you that twice the polygons don't make the game look twice as good. That's the reason I think that developers shoud go for faster framerates rather than for higher polygon counts at the exepense of lower framerates.
Sorry If something I wrote in my previous posts offended you. Believe me, I respect your points of view.
- 1,620
Hey Monton, I agree 100% with you when you elaborate. Initially you seemed to make out that there was 'never' any kind of curve to the relationship ("Its purely linear..."). Also your right when talking about polys, but I only ever meant fps / coolness factor. In my original post I mentioned the "..amount of stuff going on in game.." and then the disscussion jumped to talking strictly about poly counts!
The smiley face was meant to infer I was not actually offended... I was just surprised that my post had been misinterpreted slightly, when I tried to make it really clear what I meant. I also never specified an exact rate to the curve I was talking about either (the part under where I say "Hypothetically:" displayed an intentionally over the top curve, just to demonstrate that there was indeed a curve, I mistakenly used poly count in that section, when in hindsight I meant everything that the game has to process), so you drew your own conclusions that I meant something DRASTICALLY different to linear... (this is all assuming we're talking polys, which I wasn't, or mistakenly was. (Don't worry I'm confused too)). When talking polys, I meant to say the curve starts out really linear and then dips as bottlenecks become part of the picture.
My main point amongst all the poly talk and curve stuff, is that higher framerates should always be aimed at when making games... and you agree anyway so I've just crapped on for no reason anyway!!. Sorry I'm very repetitive also!
Hey when I said "some people can see a difference in locked 30fps vs locked 60fps..." I actually wanted to say ALL people could (understating it Aussie style), but then I thought someone might've said they can't tell the diff...(someone was previously saying that they would bet anyone to tell the difference between a locked 30 and locked 60fps) I was trying to be diplomatic. Funny how I got my own statement corrected into what I really thought!! There will always be some wackos (like you said) that are too nuts to (admit) they can't tell the difference. We agree more than you think! I have respect for everyone that has posted about the fps issue, its been interesting.
I'd buy everyone a beer if I could do that on a forum.. Oh well
The smiley face was meant to infer I was not actually offended... I was just surprised that my post had been misinterpreted slightly, when I tried to make it really clear what I meant. I also never specified an exact rate to the curve I was talking about either (the part under where I say "Hypothetically:" displayed an intentionally over the top curve, just to demonstrate that there was indeed a curve, I mistakenly used poly count in that section, when in hindsight I meant everything that the game has to process), so you drew your own conclusions that I meant something DRASTICALLY different to linear... (this is all assuming we're talking polys, which I wasn't, or mistakenly was. (Don't worry I'm confused too)). When talking polys, I meant to say the curve starts out really linear and then dips as bottlenecks become part of the picture.
My main point amongst all the poly talk and curve stuff, is that higher framerates should always be aimed at when making games... and you agree anyway so I've just crapped on for no reason anyway!!
. Sorry I'm very repetitive also! Hey when I said "some people can see a difference in locked 30fps vs locked 60fps..." I actually wanted to say ALL people could (understating it Aussie style), but then I thought someone might've said they can't tell the diff...(someone was previously saying that they would bet anyone to tell the difference between a locked 30 and locked 60fps) I was trying to be diplomatic. Funny how I got my own statement corrected into what I really thought!! There will always be some wackos (like you said) that are too nuts to (admit) they can't tell the difference. We agree more than you think! I have respect for everyone that has posted about the fps issue, its been interesting.
I'd buy everyone a beer if I could do that on a forum.. Oh well
James2097Hey Monton, I agree 100% with you when you elaborate. Initially you seemed to make out that there was 'never' any kind of curve to the relationship ("Its purely linear..."). Also your right when talking about polys, but I only ever meant fps / coolness factor. In my original post I mentioned the "..amount of stuff going on in game.." and then the disscussion jumped to talking strictly about poly counts!
The smiley face was meant to infer I was not actually offended... I was just surprised that my post had been misinterpreted slightly, when I tried to make it really clear what I meant. I also never specified an exact rate to the curve I was talking about either (the part under where I say "Hypothetically:" displayed an intentionally over the top curve, just to demonstrate that there was indeed a curve, I mistakenly used poly count in that section, when in hindsight I meant everything that the game has to process), so you drew your own conclusions that I meant something DRASTICALLY different to linear... (this is all assuming we're talking polys, which I wasn't, or mistakenly was. (Don't worry I'm confused too)). When talking polys, I meant to say the curve starts out really linear and then dips as bottlenecks become part of the picture.
My main point amongst all the poly talk and curve stuff, is that higher framerates should always be aimed at when making games... and you agree anyway so I've just crapped on for no reason anyway!!
Hey when I said "some people can see a difference in locked 30fps vs locked 60fps..." I actually wanted to say ALL people could (understating it Aussie style), but then I thought someone might've said they can't tell the diff...(someone was previously saying that they would bet anyone to tell the difference between a locked 30 and locked 60fps) I was trying to be diplomatic. Funny how I got my own statement corrected into what I really thought!! There will always be some wackos (like you said) that are too nuts to (admit) they can't tell the difference. We agree more than you think! I have respect for everyone that has posted about the fps issue, its been interesting.
I'd buy everyone a beer if I could do that on a forum.. Oh well
When an engine is well implemented the smoothness factore between 30 fps and 60 fps is almost impossible to see. It all depends on the dev. I've seen game implemented at 60 fps and it was rough and not fluid at all.
The reason why Forza is only 30 fps might be related to how the "cpu" was taxed with advance algorythm for the AI and car damage. They might be able to run it at 60fps but the framerate would not be stable.
I think the GT fans are putting too much emphasis on FPS rather then gameplay, track, car selection and available mode. this is what matter at the end. I couldn't care less if the game is 60 fps or not. As long as the control are responsive.
- 2,461
James2097Wasn't inferring anyone's telly was crap, just an entire region's TV standard...
I live in canada too and I have an HDTV set. What is the main difference between NTSC and PAL sets?
James2097Wasn't inferring anyone's telly was crap, just an entire region's TV standard...
yes my HDTV is beuuuuuuuuuuuuuuutifullll mate. (I've got to work on my steve irwin impression)
- 1,620
I want to know what the differences in regard to image quality and maximum displayable framerate are for NTSC vs PAL sets... All I know for certain is that NTSC is traditionally 50hz and PAL is 60hz. And that game reviews commonly prefer the PAL version of a game (ignoring the common horizontal black borders problem) because they simply state the graphics somehow are more colourful, have more depth and are just, well, better. Not very technical, but I'd like to know WHY?
- 1,620
And its (phrenetically) bea-uw-dee-fuwl maaaaaate! I just met a Canadian guy in a guitar store, now I'm teaching him to play Hendrix songs... Canadians seem very similar to Aussies I reckon. Really nice people, not arrogant ****s like many Americans...
Edit: Crikey this is bloody well off topic mate. Better not chinwag all night. So goodnight all.
Edit: Crikey this is bloody well off topic mate. Better not chinwag all night. So goodnight all.
- 1,620
Yep Red House is the other Canadian's fav song, so you're all the same you Canadians... I really want someone to tell us about the differences to do with PAL/NTSC in terms of game visuals...
Could GT4's or (god forbid) Forza's frame rate get worse on PAL when rejigged for 60hz?
I remember Sony's old Rapid Racer game went from 60fps to 50fps when converted to PAL... GT3 on PAL could've been 50fps as its hard to tell the diff when its 50+...
Maybe thats why Gotham2 seemed jerkier to me than other people? I think it depends HOW they convert it to PAL - with/without the black borders etc. Really don't know...
Could GT4's or (god forbid) Forza's frame rate get worse on PAL when rejigged for 60hz?
I remember Sony's old Rapid Racer game went from 60fps to 50fps when converted to PAL... GT3 on PAL could've been 50fps as its hard to tell the diff when its 50+...
Maybe thats why Gotham2 seemed jerkier to me than other people? I think it depends HOW they convert it to PAL - with/without the black borders etc. Really don't know...
- 30,026
- Cuddington, Cheshire
- JDA1982
PAL TV's have more lines on screen so they show pictures at a higher resolution, PAL games would only run at a slower frame rate if they've been converted badly. Going back to PGR2, I played and completed the PAL version which was fine frame rate wise. If anything a well converted PAL game would be smoother than an NTSC one, not the other way round.
- 2
Although this was impossible about a year ago, I have been programming the PS2 for quite a while now and want to show the difference between the hardware of the PS2 and the Xbox.
Many people judge the performance of the machine's on the comparison table's released by Microsoft shortly before the XBox was released. As with all kinds of technology, numbers and specifications do not necessarily give an impression of the performance. A lot of people believe that the speed of a machine is purely related to the amount of MHz, but obviously this is far from true.
Everything in this text is based on the PS2/XBox documentation and a properly written Dutch article about the two machines.
From now on, I will compare the machines and leave my own opinion out of the story.
1. The CPU: X-CPU@733MHz vs EE@300MHz
First of all, the CPU. The XBox has a 733 MHz Celeron clone known as the X-CPU. It has an extended instruction set supporting SSE, which can be seen as a floating point version of MMX. SSE allows multiple calculations to be performed simultaneously, by loading/storing multiple bytes/words/longwords/quadwords and perform the calculation over all these values. For example, you have 4x32 bits values in the source 128 bits register and 4x32 bits values in the destination register and only need one instruction to calculate the addition of all the 4 values.
The X-CPU has a 128 KB L2 8way setA cache and the front side bus has been increased to 133MHz instead of 100MHz. This makes the X-CPU a little bit faster than the Celeron CPU. The L1 cache is still 16KB.
The Emotion Engine Core (EE Core) CPU used in the PS2, runs at 300MHz. This seems slow for anybody who does not know technology. However, the X-CPU is only 32-bits and the EE is 128-bits. This means that it has a bus which is 4 times wider than the X-CPU. Instead of accessing only 32-bits at a time, the EE can access 128-bits instead.
The X-CPU is a CISC (Complex Instruction Set Computer) design, while the EE is a RISC (Reduced Instruction Set Computer). There are quite a few differences between the two, but it can be said that a RISC nearly always takes up only 1 clock cycle per instruction. The EE is based on the MIPS processor and therefore its architecture is a lot more modern than the X-CPU, which is backwards compatible with many older Intel CPU's. Therefore the CPU architecture is not as optimized as the EE, since it has to handle many instructions which are unnecessary. The EE can handle many parallel instructions and has a local additional FPU, SIMD (Single Instruction Multiple Data) instructions and a direct connection to the Vector Unit 0, which will be explained later.
Even benchmarks (which are usually not a good way to measure performance, but at least it gives a better impression than the clock speed) already show the difference between the two: 3.1 GFlops for the X-CPU and 6.2 GFlops for the EE. For comparison, a Pentium 4@2GHz measures at approximately 4.2 GFlops.
Unlike the X-CPU, the Emotion Engine instruction set is designed specifically for games. It can handle tasks like AI, animation, physics etc. easily and fast.
The Emotion Engine is a lot more than just a CPU. It has an MPEG 2 video decoder which can handle all the steps of DVD decoding by hardware. Only the motion compensation needs to be performed by the EE Core. This MPEG 2 decoder can also be used for decompressing images and performing any of the tasks normally used only for DVD decoding. This all happens parallel to the CPU core, so there is no CPU load.
Also connected to the EE is the DMA controller. This handles memory transfers at an extreme speed, but will be discussed later in this text.
The EE also has 16KB of (single or double buffered) ScratchPad Ram (SPR) which can be used at full speed without putting load on the memory bus. Therefore processing can still be zero waitstate even when DMA is working hard.
Also connected to the EE Core is Vector Unit 0 (VU0). This is a very fast SIMD processor which has its own memory, instruction set and operating modes. It can be used as a co-processor (macro mode) to the EE Core or as an independent processor (micro mode). The PS2 has two of those Vector Units which differ only slightly. Both VU's have 4 MAC (Multiply Accumulate: D=A*B+C) to handle high speed parallel multiply adds. The second Vector Unit, called VU1, also has special instructions for 3D graphic operations, since it is connected to the graphics processor, also known as the Graphics Synthesizer (GS).
Both Vector Units can be handled through DMA and when doing this, all the memory goes through a place called the Vector InterFace (VIF). This VIF can decompress geometry data. For example, when a set of polygons is stored in bytes (instead of 32-bits XYZW), every polygon takes up only 32-bits instead of 128. It can also do translations in hardware, so the coordinates of an object can be modified by hardware before it enters the VPU.
As you can see, it is not possible to compare the two CPU's by looking at clock speeds. While the X-CPU is really just a CPU, the EE is a lot more than that.
The EE does not necessarily need to handle any IO or sound processing. There is another computer inside the PS2, called the IOP (IO Processor). In fact this is an entire PS1 with some additional features to handle DVD streaming, IO ports, sound routines or anything you would like to run independently of the rest of the system.
Lets get to the graphics processor!
2. The GPU: 233 MHz X-GPU vs 150 MHz GS
The XBox graphics processor is the nForce IGP (Integrated Graphics Processor). The core of this GPU is the NV2A. Besides being a graphics processor, the IGP has another important task.
Since the XBox is built around a PC, it requires a North- and South-bridge. The IGP handles this and works as a North-Bridge who arbitrates between the CPU/Memory/DVD/IO/DSP.
Also here the IGP has a higher clock speed than the PS2 GS: 233MHz versus the 150MHz of the GS.
Again, a higher clock speed does not necessarily mean a higher performance. The NV2A core of the X-GPU supports 4 pixel units. This means that you can process 4 pixels per clock cycle.
The GS has 16 pixel units, with a 2048 bits bus to the frame buffer. With a simple calculation we can see the theoretical pixel fillrate of both consoles:
XBox: 233MHz x 4 pixels = 0,932 giga pixels/sec (Gp/s)
PS2: 150MHz x 16 pixels = 2,4 giga pixels/sec (Gp/s)
Note: For the PS2, halve this value when texturemapping is enabled fully (for every single object on screen, since you can independently change the renderer of each object)
Again the PS2 is a lot faster. If you look up the specifications for the XBox, you will find out that it is claimed to have 4,0 Gp/s. The explanation is as follows: The IGP has 4 hardwired FSAA units (Full Scene Anti-Aliasing, used to decrease resolution artifacts). These units can subsample 1 pixel in parallel to achieve anti-aliasing. For this reason, Microsoft says that the fillrate is 4x0,932 = approx. 4 Gp/s, although practically it cannot handle more than 0,932 Gp/s.
When we look at the amount of polygons that the two can handle, we see that the XBox totally beats the PS2: 125 million polygons/s for the XBox versus 66 million polygons/s for the PS2. However, again Microsoft has based this value on the fillrate of 4 Gp/s! This performance is based on 32 pixels/polygon, so we calculate the following: (4 Gp/s) / (32 pixels/polygon) = 125 Million polygons/s. However, as we just mentioned, there is only a maximum fillrate of 0,932 Gp/s, so the real maximum is:
XBox: (0,932 Gp/s) / (32 pixels/polygon) = 29 Mpoly/s
PS2: (2,4 Gp/s) / (32 pixels/polygon) = 75 Mpoly/s
Note: This is purely flat shaded polygon throughput
If you compare it with some older "XBox vs PS2" comparison tables, you will see that the PS2 can handle 75 million polygons per second and not 66 as mentioned there.
The X-GPU misses something important that the GS has: Embedded RAM. The GS has 4MB of on-chip local memory. This means that the GS does not take up any cycles off the main bus nor it loses cycles when others are accessing memory as on the X-GPU. This leaves the GS at full speed during texture streaming even when a device is accessing main memory.
Beside the 2048 bits wide bus from the pixel units to the frame buffer, there is also a seperate 512 bits wide bus from the frame buffer to the pixel units for the use of textures. This gives the following results:
frame buffer bandwidth: 2048bits x 150MHz = 38,4 GB/s
texture bandwidth: 512bits x 150 MHz = 9,6 GB/s
This allows a total VRAM bandwidth of 48GB/s, which is reserved ONLY for the GS!
The X-GPU has to do without local memory. This means that all its bandwidth is taken from main memory. The available bandwidth for this is 6,4 GB/s. However, this bandwidth needs to be shared between multiple devices such as the X-CPU or DSP.
Important to add is that the PS2 uses VU0 and VU1 for most of the geometry calculations, which means that depending on the amount of cycles/polygon, this reduces the amount of polygons/second. However, this is seperate from the fillrate of the graphics CPU and has advantages as well: Every object can be rendered with different characteristics, all taking up a different amount of cycles per polygon. This way it is possible to optimize the 3D environment and the programmer is the only limit when it comes to special effects etc., meaning that you are not limited to the effects of the GPU. For every object you add a micro program to the DMA packet which handles the rendering of that specific type of object. If an object is flat-shaded it uses a program for flat-shading and if procedural rendering or whatever is needed seperate programs can be used for this. It DOES require a lot of skill to do this properly, while the X-GPU is relatively easy to program.
Last but not least, the PS2 has hardware color conversion, dithering and feedback writes, so JPEG style compressed images can be decompressed using the IPU (Image Processing Unit, which is basically the MPEG 2 decoder) and directly be used as compressed textures. Feedback writes mean that the rendered output of the GS can be instantly sampled back to graphics memory to be used again and again. More about texture compression comes later!
3. The memory: 64 MB DDR SDRAM vs 32 MB RDRAM
The XBox has 4x 16MB DDR SDRAM (64 MB of 32-bits Double Data Rate SDRAM). The memory is clocked at 200MHz. Together with a 128-bits twin bank memory system it reaches a maximum theoretical bandwidth of 6,4GB/s:
200MHz x 2(DDR!) x 128bits = 51,2Gb/s = 6,4GB/s.
Beside the regular main memory, the X-CPU has 16KB of L1 instruction cache, 16KB of L1 data cache and a 128KB L2 data cache. Lets compare it with the PS2:
L1 Instruction cache:
XBox: CPU 16KB
PS2: CPU 16KB, VU0 4KB, VU1 16 KB
L1 Data cache:
XBox: 16 KB
PS2: CPU 8KB, VU0 4KB, VU1 16 KB
L2 Data cache:
XBox: 128 KB
PS2: None
Special cache:
XBox: None
PS2: SPRAM 16KB
Main Memory:
XBox: 64MB
PS2: 38MB
Bandwidth:
XBox: 6,4 GB/s
PS2: 3,2 GB/s
The PS2 has 38MB, because it also contains the 4MB of video memory and the 2MB of local memory for the IO processor (which is also the PS1).
Again you can see that the PS2 is the lesser system...or is it?
First of all, the XBox needs more RAM because it follows the PC architecture and philosophy.
This means, first put huge amounts of data such as textures in main memory, send it to the cache and start processing. This is the only way to get most out of the unified memory architecture of the XBox. The entire bandwidth needs to be shared between all the devices such as the CPU, GPU, DSP, harddisk etc.
Since it uses DDR SDRAM, the memory cannot be used optimally. For reading/writing data, DDR first needs RAS/CAS accesses. This stands for "Row Address Strobe" and "Column Address Strobe". They are used to allocate the location of data within memory. The disadvantage is the latency that they cause: The sustained bandwidth cannot be more than 60%.
NVidia has solved this problem by using twin bank memory and a four-node crossbar memory controller to queue commands. This increases the sustained bandwidth to 70%, which is roughly 4,5GB/sec.
The philosophy of the PS2 is totally different: Notice how it has different small caches. The idea is as follows: There must be a continuous stream of data to the different caches so that all the devices can be optimally used in parallel. This means that normally this data stream may never be stopped! Using the internal 128-bits buses and the 10 channel DMA controller (DMAC) this is absolutely possible. For those who do not know what DMA is: It can handle memory transfers from and to devices independent of the CPU. On the PS2, the speed of these transfers is somewhere around 2,5 GB/s.
Using the different caches and the 10 channel DMAC you can get a sustained 95% of the overal bandwidth. This gives a total main memory sustained bandwidth of approximately 3 GB/s.
SPRAM (ScratchPad RAM) is also mentioned earlier in this text and is used to keep the CPU off the main bus when possible.
While the XBox can handle a sustained 4.5 GB/s while working serially, the PS2 reaches 3GB/s+2GB/s=5GB/s with its parallel architecture.
4. The texture compression: S3TC vs CLUT
Everyone has probably heard of the word "texture", although obviously not everyone knows what it means. Well, a texture is usually an image which is wrapped on the surface of a 3D object to improve the realism or add (visual) complexity.
Since games can contain hundreds of MB of textures, it is necessary to compress them properly to decrease bandwidth usage.
If you look up the specifications of the XBox and PS2, you will notice that it says "6:1" for the XBox and "None" for the PS2. For the XBox, this means that the original texture size is decreased by 6 times, so a texture of 600kB becomes only 100kB. For the PS2, it would mean that it does not have texture compression at all. Again this is far from the truth, because the PS2 supports 8-bits CLUT (Color LookUp Table) and 4-bits CLUT compression, which decreases the texture size by 4:1 or 8:1 respectively.
With an 8-bits CLUT, every texture is stored as a 256 color image (with any palette) and with a 4-bits CLUT, textures are stored as 16-color images.
With DXTC-1, every 4x4 block of pixels (=384-bits) is converted to a block of 64-bits.
Both compression formats are lossy, which means that the quality of the image is decreased. The compression of a full image (256x256 in this case) looks better when S3TC is used.
However, there is more:
1. S3TC is only useful when higher resolutions are used.
2. On the PS2, textures consist of different sub CLUT's
Even though S3TC produces better quality textures, it does not necessarily have to look better, since both consoles are often used on a TV set. The PS2 has hardware down conversion of images and therefore the IPU (Image Processing Unit) can also be used per frame to create new banks of colourful textures from JPEG like images and convert them down if necessary.
For example, when a surface only uses gray-scales, you can use 16 colors (with or without dynamically replaced multiple palettes) and get the extra colors from light sourcing etc.
Also, 4-bits CLUT (8:1 vs 6:1) gives a better compression ratio, which is only an advantage for bandwidth usage. In the specifications of the XBox, it says that the machine has a faster fillrate for 2 textures. However, again this should be 0,932 Gp/s and not 4,0 Gp/s.
On the PS2, the fillrate does decrease every time a new texture layer is added. This is because it needs to do multi-pass rendering (each new layer adds one pass). The XBox can handle 2 textures per pixel unit without a penalty. But if we go one step further, the PS2 is again faster.
If we take a geometry of 64x64 pixels. The XBox requires 520 clock ticks for 2 textures. The PS2 needs 528 clock ticks (264 ticks per pass). However, if 3 textures are used, the XBox requires 1040 clock ticks, while the PS2 only requires 792.
5. Conclusion
The PS2 is by no means the lesser system, but it requires a lot of skill to get maximum performance out of the system. Since the XBox has a PC style architecture, it is relatively easy to program, since many software teams have experience with working on the PC. This means that an average programmer will get much more out of the XBox than out of the PS2. This is not a limitation of the hardware, but strictly of the programmer. Because of this, multi-platform games often (but not always, look at MGS2 for example) look better on the XBox, since the ports do not make maximum use of the PS2's vector units, DMA and IOP module capabilities. This is why PS2 only games often look much better than multi-platform games. It takes a long time to master the PS2, but if we look at the new generation of games, it certainly proves that the machine is still not dated. There is still no natural renderer on the XBox which compares with Metal Gear Solid 3, simply because most of this is handled by the Vector Units of the PS2. We have recently obtained the Japanese version of Gran Turismo 4 and were surprised to see that the game can even be played in 1080i mode. Some other games worth trying are Jak 2/3 and Ace Combat 5.
There are many other things worth mentioning when it comes to comparing the two machines, but since most of the hype of the XBox is about its CPU and GPU, I decided to compare those first.
Hope this clears up the ideas that people have about the modern consoles.
If GT4 would run at 30fps on the PS2, Polyphony could have doubled the detail level. But if you have good eyes you will immediately see the difference in realism caused by the framerate.
The PS2 was released way before the XBox and therefore the machine is much more revolutionary. Also, Forza is a hype even though the game has trouble to keep up with the realism of GT4. Even the Prologue version already looks a lot more realistic than the footage MS has released so far and this is from 2003.
Have you seen the Forza New York track? It proves once again that they can only imitate, not innovate or even match.
Many people judge the performance of the machine's on the comparison table's released by Microsoft shortly before the XBox was released. As with all kinds of technology, numbers and specifications do not necessarily give an impression of the performance. A lot of people believe that the speed of a machine is purely related to the amount of MHz, but obviously this is far from true.
Everything in this text is based on the PS2/XBox documentation and a properly written Dutch article about the two machines.
From now on, I will compare the machines and leave my own opinion out of the story.
1. The CPU: X-CPU@733MHz vs EE@300MHz
First of all, the CPU. The XBox has a 733 MHz Celeron clone known as the X-CPU. It has an extended instruction set supporting SSE, which can be seen as a floating point version of MMX. SSE allows multiple calculations to be performed simultaneously, by loading/storing multiple bytes/words/longwords/quadwords and perform the calculation over all these values. For example, you have 4x32 bits values in the source 128 bits register and 4x32 bits values in the destination register and only need one instruction to calculate the addition of all the 4 values.
The X-CPU has a 128 KB L2 8way setA cache and the front side bus has been increased to 133MHz instead of 100MHz. This makes the X-CPU a little bit faster than the Celeron CPU. The L1 cache is still 16KB.
The Emotion Engine Core (EE Core) CPU used in the PS2, runs at 300MHz. This seems slow for anybody who does not know technology. However, the X-CPU is only 32-bits and the EE is 128-bits. This means that it has a bus which is 4 times wider than the X-CPU. Instead of accessing only 32-bits at a time, the EE can access 128-bits instead.
The X-CPU is a CISC (Complex Instruction Set Computer) design, while the EE is a RISC (Reduced Instruction Set Computer). There are quite a few differences between the two, but it can be said that a RISC nearly always takes up only 1 clock cycle per instruction. The EE is based on the MIPS processor and therefore its architecture is a lot more modern than the X-CPU, which is backwards compatible with many older Intel CPU's. Therefore the CPU architecture is not as optimized as the EE, since it has to handle many instructions which are unnecessary. The EE can handle many parallel instructions and has a local additional FPU, SIMD (Single Instruction Multiple Data) instructions and a direct connection to the Vector Unit 0, which will be explained later.
Even benchmarks (which are usually not a good way to measure performance, but at least it gives a better impression than the clock speed) already show the difference between the two: 3.1 GFlops for the X-CPU and 6.2 GFlops for the EE. For comparison, a Pentium 4@2GHz measures at approximately 4.2 GFlops.
Unlike the X-CPU, the Emotion Engine instruction set is designed specifically for games. It can handle tasks like AI, animation, physics etc. easily and fast.
The Emotion Engine is a lot more than just a CPU. It has an MPEG 2 video decoder which can handle all the steps of DVD decoding by hardware. Only the motion compensation needs to be performed by the EE Core. This MPEG 2 decoder can also be used for decompressing images and performing any of the tasks normally used only for DVD decoding. This all happens parallel to the CPU core, so there is no CPU load.
Also connected to the EE is the DMA controller. This handles memory transfers at an extreme speed, but will be discussed later in this text.
The EE also has 16KB of (single or double buffered) ScratchPad Ram (SPR) which can be used at full speed without putting load on the memory bus. Therefore processing can still be zero waitstate even when DMA is working hard.
Also connected to the EE Core is Vector Unit 0 (VU0). This is a very fast SIMD processor which has its own memory, instruction set and operating modes. It can be used as a co-processor (macro mode) to the EE Core or as an independent processor (micro mode). The PS2 has two of those Vector Units which differ only slightly. Both VU's have 4 MAC (Multiply Accumulate: D=A*B+C) to handle high speed parallel multiply adds. The second Vector Unit, called VU1, also has special instructions for 3D graphic operations, since it is connected to the graphics processor, also known as the Graphics Synthesizer (GS).
Both Vector Units can be handled through DMA and when doing this, all the memory goes through a place called the Vector InterFace (VIF). This VIF can decompress geometry data. For example, when a set of polygons is stored in bytes (instead of 32-bits XYZW), every polygon takes up only 32-bits instead of 128. It can also do translations in hardware, so the coordinates of an object can be modified by hardware before it enters the VPU.
As you can see, it is not possible to compare the two CPU's by looking at clock speeds. While the X-CPU is really just a CPU, the EE is a lot more than that.
The EE does not necessarily need to handle any IO or sound processing. There is another computer inside the PS2, called the IOP (IO Processor). In fact this is an entire PS1 with some additional features to handle DVD streaming, IO ports, sound routines or anything you would like to run independently of the rest of the system.
Lets get to the graphics processor!
2. The GPU: 233 MHz X-GPU vs 150 MHz GS
The XBox graphics processor is the nForce IGP (Integrated Graphics Processor). The core of this GPU is the NV2A. Besides being a graphics processor, the IGP has another important task.
Since the XBox is built around a PC, it requires a North- and South-bridge. The IGP handles this and works as a North-Bridge who arbitrates between the CPU/Memory/DVD/IO/DSP.
Also here the IGP has a higher clock speed than the PS2 GS: 233MHz versus the 150MHz of the GS.
Again, a higher clock speed does not necessarily mean a higher performance. The NV2A core of the X-GPU supports 4 pixel units. This means that you can process 4 pixels per clock cycle.
The GS has 16 pixel units, with a 2048 bits bus to the frame buffer. With a simple calculation we can see the theoretical pixel fillrate of both consoles:
XBox: 233MHz x 4 pixels = 0,932 giga pixels/sec (Gp/s)
PS2: 150MHz x 16 pixels = 2,4 giga pixels/sec (Gp/s)
Note: For the PS2, halve this value when texturemapping is enabled fully (for every single object on screen, since you can independently change the renderer of each object)
Again the PS2 is a lot faster. If you look up the specifications for the XBox, you will find out that it is claimed to have 4,0 Gp/s. The explanation is as follows: The IGP has 4 hardwired FSAA units (Full Scene Anti-Aliasing, used to decrease resolution artifacts). These units can subsample 1 pixel in parallel to achieve anti-aliasing. For this reason, Microsoft says that the fillrate is 4x0,932 = approx. 4 Gp/s, although practically it cannot handle more than 0,932 Gp/s.
When we look at the amount of polygons that the two can handle, we see that the XBox totally beats the PS2: 125 million polygons/s for the XBox versus 66 million polygons/s for the PS2. However, again Microsoft has based this value on the fillrate of 4 Gp/s! This performance is based on 32 pixels/polygon, so we calculate the following: (4 Gp/s) / (32 pixels/polygon) = 125 Million polygons/s. However, as we just mentioned, there is only a maximum fillrate of 0,932 Gp/s, so the real maximum is:
XBox: (0,932 Gp/s) / (32 pixels/polygon) = 29 Mpoly/s
PS2: (2,4 Gp/s) / (32 pixels/polygon) = 75 Mpoly/s
Note: This is purely flat shaded polygon throughput
If you compare it with some older "XBox vs PS2" comparison tables, you will see that the PS2 can handle 75 million polygons per second and not 66 as mentioned there.
The X-GPU misses something important that the GS has: Embedded RAM. The GS has 4MB of on-chip local memory. This means that the GS does not take up any cycles off the main bus nor it loses cycles when others are accessing memory as on the X-GPU. This leaves the GS at full speed during texture streaming even when a device is accessing main memory.
Beside the 2048 bits wide bus from the pixel units to the frame buffer, there is also a seperate 512 bits wide bus from the frame buffer to the pixel units for the use of textures. This gives the following results:
frame buffer bandwidth: 2048bits x 150MHz = 38,4 GB/s
texture bandwidth: 512bits x 150 MHz = 9,6 GB/s
This allows a total VRAM bandwidth of 48GB/s, which is reserved ONLY for the GS!
The X-GPU has to do without local memory. This means that all its bandwidth is taken from main memory. The available bandwidth for this is 6,4 GB/s. However, this bandwidth needs to be shared between multiple devices such as the X-CPU or DSP.
Important to add is that the PS2 uses VU0 and VU1 for most of the geometry calculations, which means that depending on the amount of cycles/polygon, this reduces the amount of polygons/second. However, this is seperate from the fillrate of the graphics CPU and has advantages as well: Every object can be rendered with different characteristics, all taking up a different amount of cycles per polygon. This way it is possible to optimize the 3D environment and the programmer is the only limit when it comes to special effects etc., meaning that you are not limited to the effects of the GPU. For every object you add a micro program to the DMA packet which handles the rendering of that specific type of object. If an object is flat-shaded it uses a program for flat-shading and if procedural rendering or whatever is needed seperate programs can be used for this. It DOES require a lot of skill to do this properly, while the X-GPU is relatively easy to program.
Last but not least, the PS2 has hardware color conversion, dithering and feedback writes, so JPEG style compressed images can be decompressed using the IPU (Image Processing Unit, which is basically the MPEG 2 decoder) and directly be used as compressed textures. Feedback writes mean that the rendered output of the GS can be instantly sampled back to graphics memory to be used again and again. More about texture compression comes later!
3. The memory: 64 MB DDR SDRAM vs 32 MB RDRAM
The XBox has 4x 16MB DDR SDRAM (64 MB of 32-bits Double Data Rate SDRAM). The memory is clocked at 200MHz. Together with a 128-bits twin bank memory system it reaches a maximum theoretical bandwidth of 6,4GB/s:
200MHz x 2(DDR!) x 128bits = 51,2Gb/s = 6,4GB/s.
Beside the regular main memory, the X-CPU has 16KB of L1 instruction cache, 16KB of L1 data cache and a 128KB L2 data cache. Lets compare it with the PS2:
L1 Instruction cache:
XBox: CPU 16KB
PS2: CPU 16KB, VU0 4KB, VU1 16 KB
L1 Data cache:
XBox: 16 KB
PS2: CPU 8KB, VU0 4KB, VU1 16 KB
L2 Data cache:
XBox: 128 KB
PS2: None
Special cache:
XBox: None
PS2: SPRAM 16KB
Main Memory:
XBox: 64MB
PS2: 38MB
Bandwidth:
XBox: 6,4 GB/s
PS2: 3,2 GB/s
The PS2 has 38MB, because it also contains the 4MB of video memory and the 2MB of local memory for the IO processor (which is also the PS1).
Again you can see that the PS2 is the lesser system...or is it?
First of all, the XBox needs more RAM because it follows the PC architecture and philosophy.
This means, first put huge amounts of data such as textures in main memory, send it to the cache and start processing. This is the only way to get most out of the unified memory architecture of the XBox. The entire bandwidth needs to be shared between all the devices such as the CPU, GPU, DSP, harddisk etc.
Since it uses DDR SDRAM, the memory cannot be used optimally. For reading/writing data, DDR first needs RAS/CAS accesses. This stands for "Row Address Strobe" and "Column Address Strobe". They are used to allocate the location of data within memory. The disadvantage is the latency that they cause: The sustained bandwidth cannot be more than 60%.
NVidia has solved this problem by using twin bank memory and a four-node crossbar memory controller to queue commands. This increases the sustained bandwidth to 70%, which is roughly 4,5GB/sec.
The philosophy of the PS2 is totally different: Notice how it has different small caches. The idea is as follows: There must be a continuous stream of data to the different caches so that all the devices can be optimally used in parallel. This means that normally this data stream may never be stopped! Using the internal 128-bits buses and the 10 channel DMA controller (DMAC) this is absolutely possible. For those who do not know what DMA is: It can handle memory transfers from and to devices independent of the CPU. On the PS2, the speed of these transfers is somewhere around 2,5 GB/s.
Using the different caches and the 10 channel DMAC you can get a sustained 95% of the overal bandwidth. This gives a total main memory sustained bandwidth of approximately 3 GB/s.
SPRAM (ScratchPad RAM) is also mentioned earlier in this text and is used to keep the CPU off the main bus when possible.
While the XBox can handle a sustained 4.5 GB/s while working serially, the PS2 reaches 3GB/s+2GB/s=5GB/s with its parallel architecture.
4. The texture compression: S3TC vs CLUT
Everyone has probably heard of the word "texture", although obviously not everyone knows what it means. Well, a texture is usually an image which is wrapped on the surface of a 3D object to improve the realism or add (visual) complexity.
Since games can contain hundreds of MB of textures, it is necessary to compress them properly to decrease bandwidth usage.
If you look up the specifications of the XBox and PS2, you will notice that it says "6:1" for the XBox and "None" for the PS2. For the XBox, this means that the original texture size is decreased by 6 times, so a texture of 600kB becomes only 100kB. For the PS2, it would mean that it does not have texture compression at all. Again this is far from the truth, because the PS2 supports 8-bits CLUT (Color LookUp Table) and 4-bits CLUT compression, which decreases the texture size by 4:1 or 8:1 respectively.
With an 8-bits CLUT, every texture is stored as a 256 color image (with any palette) and with a 4-bits CLUT, textures are stored as 16-color images.
With DXTC-1, every 4x4 block of pixels (=384-bits) is converted to a block of 64-bits.
Both compression formats are lossy, which means that the quality of the image is decreased. The compression of a full image (256x256 in this case) looks better when S3TC is used.
However, there is more:
1. S3TC is only useful when higher resolutions are used.
2. On the PS2, textures consist of different sub CLUT's
Even though S3TC produces better quality textures, it does not necessarily have to look better, since both consoles are often used on a TV set. The PS2 has hardware down conversion of images and therefore the IPU (Image Processing Unit) can also be used per frame to create new banks of colourful textures from JPEG like images and convert them down if necessary.
For example, when a surface only uses gray-scales, you can use 16 colors (with or without dynamically replaced multiple palettes) and get the extra colors from light sourcing etc.
Also, 4-bits CLUT (8:1 vs 6:1) gives a better compression ratio, which is only an advantage for bandwidth usage. In the specifications of the XBox, it says that the machine has a faster fillrate for 2 textures. However, again this should be 0,932 Gp/s and not 4,0 Gp/s.
On the PS2, the fillrate does decrease every time a new texture layer is added. This is because it needs to do multi-pass rendering (each new layer adds one pass). The XBox can handle 2 textures per pixel unit without a penalty. But if we go one step further, the PS2 is again faster.
If we take a geometry of 64x64 pixels. The XBox requires 520 clock ticks for 2 textures. The PS2 needs 528 clock ticks (264 ticks per pass). However, if 3 textures are used, the XBox requires 1040 clock ticks, while the PS2 only requires 792.
5. Conclusion
The PS2 is by no means the lesser system, but it requires a lot of skill to get maximum performance out of the system. Since the XBox has a PC style architecture, it is relatively easy to program, since many software teams have experience with working on the PC. This means that an average programmer will get much more out of the XBox than out of the PS2. This is not a limitation of the hardware, but strictly of the programmer. Because of this, multi-platform games often (but not always, look at MGS2 for example) look better on the XBox, since the ports do not make maximum use of the PS2's vector units, DMA and IOP module capabilities. This is why PS2 only games often look much better than multi-platform games. It takes a long time to master the PS2, but if we look at the new generation of games, it certainly proves that the machine is still not dated. There is still no natural renderer on the XBox which compares with Metal Gear Solid 3, simply because most of this is handled by the Vector Units of the PS2. We have recently obtained the Japanese version of Gran Turismo 4 and were surprised to see that the game can even be played in 1080i mode. Some other games worth trying are Jak 2/3 and Ace Combat 5.
There are many other things worth mentioning when it comes to comparing the two machines, but since most of the hype of the XBox is about its CPU and GPU, I decided to compare those first.
Hope this clears up the ideas that people have about the modern consoles.
If GT4 would run at 30fps on the PS2, Polyphony could have doubled the detail level. But if you have good eyes you will immediately see the difference in realism caused by the framerate.
The PS2 was released way before the XBox and therefore the machine is much more revolutionary. Also, Forza is a hype even though the game has trouble to keep up with the realism of GT4. Even the Prologue version already looks a lot more realistic than the footage MS has released so far and this is from 2003.
Have you seen the Forza New York track? It proves once again that they can only imitate, not innovate or even match.
PeyoteAmiga
All this is good but you forgot something : Vertex and Pixel shading is not part of the PS2 GPU. The technology have change from just polygon / texture to simple pologoning and normal map / vertex and pixel shading. The xbox gpu support thos function and this why the game looks better on xbox.
- 344
PeyoteAmiga
Assuming that all of the previous infomation is correct then I have a question, why would sony create such a backward system to program? And can we expect them to correct this problem so that we can look forward to much simpilar program systems. Also why is it so hard to get the most out of the PS2. I understand why the X-box is so easy but I don't understand why the PS2 is so hard.
I'm tending to believe PeyoteAmiga, it seems like he certainly knows his stuff. It appears like the only limiting factor between the Xbox and the PS2 is the amount of effort and work a company is willing to put into their game. A company like PD that invests a lot of time and care and attention into their work can produce a game that is an equal to anything on the Xbox. However, because the Xbox is using programming that is more familiar to people, it is somewhat easier for them to program for.
It looks like Microsoft went for the easier brute force route and Sony went for the more elegant, but perhaps not as effective, route.
I think it'll be very interesting to see the next generations of consoles.
It looks like Microsoft went for the easier brute force route and Sony went for the more elegant, but perhaps not as effective, route.
I think it'll be very interesting to see the next generations of consoles.
- 2
Symtex
Obviously you know very well what you are talking about! I would like to add that the PS2 has no perspective correct mapping, can only handle 1 million two-sided polygons per second and the Dreamcast is much more powerful! Better get Metropolis Street Racer now, those PS2 fanboys are too biased!
What is your definition of GPU? The Graphics Synthesizer? On the PS2, the VU's and DMA (and other things) are also part of the GPU. Use the hardware properly and you can do any of the things you mentioned. Many games programmers have shown this already since a looong time. That is the difference: On the XBox you get standard features in the 3D hardware and on the PS2 you have to program everything by yourself, thus creating more flexibility to add special effects.
Maybe I should have mentioned more about the "superior" alpha channel and overdrawing features of the XBox. :-P
- 309
http://ps2.ign.com/articles/588/588077p1.html you guys would prob be interested in this if you already havnt seen it... i did a search an came up empty..so enjoy!
So, do we know if GT4 has taillights and skidmarks yet?
- 357
of course it has tailights. Reverse lights are a different story. no skids either
- 200
Well of course it has tailights, they have been in since GT1. As for reverse lights, no. And skidmarks, no.MuscleCarMan13
EDIT- Curse! Too slow.
Similar threads
