one said:
jvd said:
Today PS2 is seen as less powerful machine than newer Xbox, but if PS2 had had more memory, and if Toshiba had not misestimated future GPU trend in designing GS...?
Lets have a look at this in 'reality'. Lets look at something 'compareble'
PS2 has 2 general purpose vector units, clocked at 300Hz. Capable of a limited set of 16 bit integer ops and 1 vector dotproduct per cycle. It has looping and primitive generation capabilities.
Xbox has 2 vertex units, clocked at 233Hz. Capable of 1 vector dotproduct per cycle.
Clear win to PS2, lets look closer. Clear high theorical speeds for PS2.
Xbox vertex shader are 6 way SMT. It has 6 threads, that switch automatically when latency would stall the pipes, it also does the homogenous divide and clipping for 'free' (pipeline fixed function).
PS2 rely on manual loop unrolling to hide latency, in many cases the register don't have interlocks so its down to NOP counting. Its LIW make it hard.
Clear win to Xbox this round. Xbox is much easier to program for.
Overall realworld performance, Xbox is faster but then it should be its several years later silicon. PS2 manages to hold it head up VERY well considering how much earlier it was designed and implemented. Its a testiment to the awesome design skills of ST (Sony and Toshiba) that they managed to put so much pure float power in such an early console.
But it also shows a brute-force un-user friendly approach. A good analogy would be modern jets, the early experimental X planes did get to Mach 1 or 2 but modern jets get to a similar speed alot safer.
ATI and NVIDIA have shown how to get good graphics performance relatively easily. Sony have shown pure brute force and good coders can get good graphics performance.
Deano, PSOne seemed to be a user freindly, powerful conssole.
The idea with PlayStation 2 was to let developers close to the metal and give them the fastest architecfture they could design at that time.
To do that they needed a very brute force approach.
I think they understood now that maybe it is the mix between the two approaches that they need as MS got its cards right with Xbox 2.
Personally an idea for the EE would have been to take VU0, strip it of the lower integer pipeline (including the branch unit and all) and attach it permanently to the CO-OP pipe making it a co-processor for the EE RISC core (yes, the VIF0 would go away too).
Then attach to the RISC core a nice 128 KB L2 cache from which the two ALU units, the FPU and VU0 could be fed from (if the data they wanted was not in the L1 cache or in the SPRAM).
Would have this yeld higher max FP performance for VU0 ? No.
Would have this make the VU0 more useable by developers ? IMHO Yes.
Macro-mode as it is now slows the CPU down as it kicks where it hirts the most: lack of good cache hierarchy for the RISC core.
With 128 KB of L2 cache the situation would be different.
Now, look at PSP.
.
They do learn from their mistakes: true, we do not see a big L2 cache... but...
We do not have VU1 to steal main memory accesses, the CPU is only a single-banger (single-issue) processor and quite probably the VFPU is an extension of the regular FPU like we see on the SH-4 CPU.
PSP manages in a portable to offer PlayStation 2 like performance with an easier to program platform (more user friendly).
That is the advantage of newer technology (nice 90 nm manufacturing process) and hindsight, experience.
PSP was designed to be programmed with a higher level API in mind, so was PSOne.
I think PlayStation 3 will try, as much as they can, to go towards that direction.
I do not think they will go crazy with the number of APUs and PEs for that reason.