PS2 EE question

There are probably some tasks where the EE taken as a whole could be faster than the Pentium 3

As a whole, you mean in using VU1, VU0 etc too?

To paraphrase one of the developers that used to post here, the P3 was a lot faster at anything you'd actually be running on it.

Yeah having read that too, someone named ERP. But then again he didnt specify if that was EE+VU0 against the P3. Aside from that, its allways a good thing to hear from others too what their take is. Theres even people that said otherwise, but they were probally not developers or experts.
 
As a whole, you mean in using VU1, VU0 etc too?

Yeah. The vector units are part of the EE.

Yeah having read that too, someone named ERP. But then again he didnt specify if that was EE+VU0 against the P3. Aside from that, its allways a good thing to hear from others too what their take is. Theres even people that said otherwise, but they were probally not developers or experts.

I image that without the vector units the EE would hopelessly outmatched by a P3 at just about anything.
 
I image that without the vector units the EE would hopelessly outmatched by a P3 at just about anything.

How about when EE is helped out by VU0 (in micromode), P3 still faster for most things?
Also wondering, on PS2 the IOP takes care of the networking (37mhz?), how is that on xbox, through the main cpu, or some processor on the mainboard?
 
Also wondering, on PS2 the IOP takes care of the networking (37mhz?), how is that on xbox, through the main cpu, or some processor on the mainboard?
Nah, network stack in Xbox ran on main CPU, it's not a particularly burdensome task. Not sure if the original box supported 100mbit/s ethernet, but even if it did, at the rates broadband ran back in the day it would not have been a heavy task.

PS2 had that I/O processor because its main CPU is not very powerful at running general code, and the I/O processor doubled as Playstation backwards compatibility CPU also, so might as well tack some extra duties onto it because why the hell not. :p
 
That explains alot, copying from and to anog xbox using ftp i get 11mb/s. PS2 you can be happy to get 2mb/s. On some forum they said it would be faster if the ps2 could use mips core for networking, but thats not possible due to its structure or something like that.

That said with ps2 you can play games/stream over network though with lag, as the iop is too slow to keep up. Xbox doesnt let you stream games, but movies without a problem. Wonder if streaming games would take away too much cpu? But should be same for movies then...
Xbox is 100mbits full duplex yes.
 
PS2 you can be happy to get 2mb/s.
At least the early PS2s that had the expansion bay attached its network adapter via PCMCIA interface. This is not a very fast bus. While it probably should offer more than 2Mbit/s, who knows how the hardware was engineered under the hood. It might have been some super ugly hack of an interface. *shrug*
 
At least the early PS2s that had the expansion bay attached its network adapter via PCMCIA interface. This is not a very fast bus. While it probably should offer more than 2Mbit/s, who knows how the hardware was engineered under the hood. It might have been some super ugly hack of an interface. *shrug*
Like PS4's HDD? :p
 
Like PS4's HDD? :p
Well, yeah... Sorta. :p Although no HDD was actually bottlenecked by the USB to SATA bridge hack, it was more a slight performance loss on SSDs kind of thing.

PS4 has native SATA for onboard drive now though, yeah? I seem to recall reading something along those lines.
 
Then what is this table talking about under 'sound related functions'. http://wars.locopuyo.com/cwsystemspecsold.php
It lists three DSP cores, for PS2 36mhz (must be the IOP?).

According to wikipedia VU0 has 2.44Gflops, but nothing about the main mips core. It must have some floating point ability too? XCPU is listed as a little over 3Gflops, in case how does the XCPU compare to VU0 and EE working together?
 
Then what is this table talking about under 'sound related functions'. http://wars.locopuyo.com/cwsystemspecsold.php
It lists three DSP cores, for PS2 36mhz (must be the IOP?).

According to wikipedia VU0 has 2.44Gflops, but nothing about the main mips core. It must have some floating point ability too? XCPU is listed as a little over 3Gflops, in case how does the XCPU compare to VU0 and EE working together?

The "Three DSP cores" is mentioned under the Xbox audio solution. The Xbox had by far the best audio processor of the three systems, so perhaps it really did need 3 DSPs to handle all 64 3D channels, but I'm doubtful all the data on that page is correct. Alot of it is inconsistent or wrong.

And you should be asking "how does the XCPU compare to the MIPS core + FPU + VU0 working together?" The FPU and VU0 are technically coprocessors under the MIPS scheme. VU1 is connected by DMA but overall these components + others are collectively part of the Emotion Engine.

slide_4.jpg

You can readily see how each part of the EE is connected to other parts, like how VU1 is separated from the MIPS core but given it's own direct bus to the Graphics Synthesizer.
 
Last edited:
Well, yeah... Sorta. :p Although no HDD was actually bottlenecked by the USB to SATA bridge hack, it was more a slight performance loss on SSDs kind of thing.

PS4 has native SATA for onboard drive now though, yeah? I seem to recall reading something along those lines.
Wait, did launch PS4's use a USB to SATA bridge for the internal hard drive? What about the optical drive?
 
Wait, did launch PS4's use a USB to SATA bridge for the internal hard drive?
Yeah. :p Apparently, it made ARM Trustzone whatchamacallits implementation easier/more robust or whatever. Or so someone technical said on a forum I read somewhere, I don't recall the specifics...

What about the optical drive?
Some proprietary interface of some sort.
 
There are probably some tasks where the EE taken as a whole could be faster than the Pentium 3, at least on paper. But it's most useful, I think, to judge them by the workloads they ran.

To paraphrase one of the developers that used to post here, the P3 was a lot faster at anything you'd actually be running on it.

According to this guy, they actually had more issues with performance on the p3 when making burnout 3.

http://www.sega-16.com/forum/showth...mcast-Graphics&p=640583&viewfull=1#post640583

There were other posts but the thread is huge and I can't find them.
 
The Xbox had by far the best audio processor of the three systems

Almost every game has support for dd5.1, atleast all the games ive played/have, even Doom 3 does, the DSP's sure must offload the CPU by a large margin.

And you should be asking "how does the XCPU compare to the MIPS core + FPU + VU0 working together?"

Yes thats what im asking, or atleast thats what im intending to :) I think thats the most fair comparison to the XCPU, as that seems how the PS2 was used, and should be used. Without VU1 the GS wont be displaying such impressive graphics i guess.
Looking at that diagram the PS2 looks like a hell of a complex system, thoughts go to Naughty Dog/Konami for using every part to the max with the syncing of it all in mind.

According to this guy, they actually had more issues with performance on the p3 when making burnout 3.

Forum-poster gamevet was asking 'if the EE and its vector units' were as powerfull as a P3 733 (guessing XCPU). That means the whole EE with VU1 and VU0.
Someone answered that the EE was faster sometimes, as i understand physics/collision. Again not really clear if he means VU0 and EE mips core, or with VU1, but seeing the question was with vector units then the EE as a whole must be really weak if it sometimes outperforms the single XCPU in some calculations?
Anyways i have asked here not long time ago, got an answer that P3 733 xcpu is faster compaired to EE+VU0 working together, but i wanted to hear more opinions as there seem to be alot of mixed answers all over the net, like the sega-16 forums and to an extend on b3d.
Also wasnt burnout a PS2 oriented game/the lead platform, but optimized for other platforms by different teams? Remember reading that somewhere.
 
According to this guy, they actually had more issues with performance on the p3 when making burnout 3.
They may have run into memory contention issues, due to xbox's UMA design. The xbox CPU was in of itself by far the strongest overall of that generation of consoles and ordinarily should not have been a bottleneck.
 
Are you comparing that to PS2's VU0+EE/FPU working together?
Yeah, overall, barring any corner cases it pretty much owned the other consoles' CPUs. :p

The P3 was much higher clocked than any of the other consoles' CPUs, had a fairly roomy and quite fast L2 cache (256 bit read/write per clock IIRC), it was out-of-order execution capable and superscalar (which out of the others, only the Gamecube's PPC CPU was somewhat out-of-order, but not as advanced as the P3.) Plus, the SSE SIMD FP unit didn't require any jumping through hoops like the vector units of the EE did; it ran ordinary program code, like the integer ALUs or the x87 FPU did.

Of course, the xbox also was expensive. So you can't really have cake AND eat it. :D If you try to build the wickedest console with the best of the best and extra everything...it's going to cost a lot of money... :)
 
They may have run into memory contention issues, due to xbox's UMA design. The xbox CPU was in of itself by far the strongest overall of that generation of consoles and ordinarily should not have been a bottleneck.

I think so too, but I'm wondering if there could be situations - edge cases - where the Xbox CPU might not have been easily able to soak up all the load from DX and hand tuned PS2 Vector code, and actually needed optimisation work (and not just the PS2 game thrown at a dev kit).

For example, image a Burnout 2 like game with lots of high frequency physics calculations and physics based deformation of (for the time) high poly models. Now image the game is designed around a 16 ms window and very well optimised for PS2. The Xbox version is a port also headed to bog standard DX on PC as well as GC, and so you're using a high level DX implementation (not ERP low level optimised) that soaks up 50% of your CPU time (not normally a problem for ports).

You have a collision with all kinds of deformation and destruction and it's heavily vectorised and predictable in terms of datasets. That suits the EE, but on Xbox its massively powerful vertex shaders can't really help. Might that require some optimisation to always fit in your 16 ms window?

Can't say for sure obviously, but there has to be a point where for all its speed the P3 can no longer be guaranteed to simply soak up large rendering overheads and run auto compiled implementations of algorithms optimised for radically different hardware...? *shrug*
 
had a fairly roomy and quite fast L2 cache (256 bit read/write per clock IIRC)

Wasnt it 128kb for the XCPU? Its still alot more then the PS2's cpu though.

Of course, the xbox also was expensive.

It was very expensive for microsoft, according to this article they lost over 4 billion by 2005. Wouldnt suprise me if it was way more then that. Think Sony did better with the PS2 :)
https://www.engadget.com/2005/09/26/forbes-xbox-lost-microsoft-4-billion-and-counting/

How about the GPU though, then its NV2A against PS2's VU1+GS and its 4md eDRAM, just assuming the NV2A was much more capable overall as its design was like a GF3/4, which wasnt a bad GPU.

For system memory, PS2 had the higher-cost Rambus ram, 32mb of it and 4mb eDRAM (only for textures?), in the other corner we have the xbox with its 64MB ram for the whole system, more isnt always better so have no idea whos console had the memory advantage :p


@function

If VU1 was doing some work too i can understand it wont run as fast on the P3, it wasnt really there for graphics.
Found this article awhile ago too;
https://www.gamasutra.com/view/feature/131296/porting_a_ps2centric_game_to_the_.php
Seems like you describe, hand written vecture unit code, that didnt run as well on the xbox. If im understanding right they used both vector units to calculate animations, whilst on xbox the CPU was doing this?

Then they said something about the FPU being more robust in EE when it came to bugs. All in all they had to make the animations more simple or the same, but achieved 60fps opposed to PS2's 30, with updated graphics to boot.

Wonder if they could have done more, or use a vertex shader for the animation system? Anyways read the article, you guys understand more of that then i do :p
 
Wasnt it 128kb for the XCPU? Its still alot more then the PS2's cpu though.
128k L2 is actually infinitely more than in EE's CPU, which had zero L2. :p CPU had 16k scratchpad SRAM, but this was not a cache - it was software managed; plus it was rather small as well, so overall a lot more hand optimization needed compared to a relatively roomy L2 which manages itself automatically*.

*Some CPU caches have the ability to manually "lock" certain cache lines, making their contents permanent; thus eliminating the possibility that important code gets flushed out, perhaps by something fairly trivial, thus causing performance loss. This is useful in specific applications like in a console, or perhaps say, a networking router or other system where you have control over what code runs at any given time. It would be of limited usefulness in a multitasking system like a PC for example.
 
Back
Top