what about the fact that NGP will have quad-core cpu , quad-core gpu & dedicated media chips
wouldn't that make it easier to split the PS2 emulation up into small jobs for each core ?
Not only can you not split one CPU-like core into multiple threads in emulations, but you often can't even split many CPU-like cores into multiple threads in emulation.
Take an example from Nintendo DS: there are two CPU cores, an ARM9 and an ARM7. There's a Nintendo library software communication procedure that works by having one core tell something to the other and the other sends a response showing it got the message. The sending core will spin a loop for a (relatively small, think dozens) number of iterations waiting for that response, and if it doesn't get it afterwards it assumes the thing is broken and everything stops dead in its tracks.
If you're emulating these cores on two separate threads - let's assume you've been able to peg them as executing simultaneously on different cores, because otherwise you're already screwed - you've got a massive realtime requirement that can be difficult or impossible to meet. If, during this attempt at communication, core B is somehow stalled for only dozens of CPU cycles you're going to be hosed. Even if you're running this stuff in a real-time OS without preemptive multitasking and no virtual address space or anything, an interrupt or even an outer-level cache miss can screw you. Not to mention, you still need to emulate other things aside from CPU cores so if anything needs to share resources you're hosed.
PCSX2 traditionally had a multitasking parameter of switching which CPU it executed every 512 clock cycles. Presumably a clock cycle corresponded to emulating 1 or maybe some small N instructions in at least most cases, for the EE anyway. I don't know where this number came from, but I know that the developers warned against trying to change it to improve performance, so I presume it was picked for a reason.
Another big challenge with PS2 emulation is that the FPU and VUs don't handle infinity/NaN (and also therefore have a larger dynamic range) and this can't be emulated fully correctly on an FPU that, and workarounds have to be made in order to try to make things passable. FPU compatibility problems are a nightmare for emulation, and are just one example where not having the right kind of specialized hardware means you'll either have compatibility problems or will spend tons of CPU cycles emulating something in software. Never underestimate how many machine instructions it can take to emulate something hardware can do in one clock cycle.
PS3 did manage to emulate EE, and I don't know how it attempted to split resources. But the results were less than amazing, with compatibility and performance problems plaguing many games. Providing a user experience that's this unreliable (such as games randomly locking or being unable to progress past a certain point) can become more of a liability than its worth.
& what about the PSP emulation? isn't that being done without using PSP parts?
1) Regardless of what anyone says, PSP is a lot simpler than PS2
2) PSP benefits from having a great deal of its hardware abstracted off by the operating system, something that's impossible to circumvent in game titles, much unlike PS2, and this might mean less tight synchronization is needed as well
3) Only a very specific set of titles are being emulated, not at all a general purpose emulator meant for backwards compatibility.. it's entirely possible that the games were made under a set of constraints to make emulation easier
4) PS3 has way more single threaded and vector performance than NGP will
it's 11 years later PS2 can be emulated by Sony without using the same PS2 parts this is not some guys in their basements trying to emulate PS2 on different types of PC setups with different hardware & OS it's Sony making new hardware knowing what's needed to get the job done & knowing what held it back on the PS3
Those "guys in their basements" have proven time and again that they're capable of matching commercial quality in emulation. Companies don't have secret sauce for improving performance and often times don't know much more about the hardware than people have figured out on their own (or gleaned from leaked documents...). They may be in more of a position to compromise compatibility for performance, but I'm not sure that is on the table for this discussion.
To a large extent Sony is probably not really "making new hardware" either, as much as they're gluing together available IP blocks.
everything about the NGP isn't known yet so I wouldn't be so quick to say it's not going to happen just because it's not working on the PS3. I seen a PSP attempt to emulate a dreamcast so I have a hard time believing that Sony can't emulate PS2 on new hardware that they are releasing 11 years after the PS2 they can pretty much have PS2 as SoC now.
Yeah, the operative word being "attempt." No doubt someone could port PCSX2 to NGP if they had the ability to run software, but it'd run poorly, just like the port of nullDC to PSP. I figured when talking about BC we were talking about the kind where the game runs at the right speed.
They could have PS2 as an SoC now, but even with a shrink all the way to 40nm it'd probably still take more die space than is worthwhile.
plus it seems like they have more to gain from having PS2 games on PSN for NGP than they did having people play their old PS2 games on the PS3.
If they're going to rerelease games they can port them.
ToTTenTranz said:
So you don't think Xenos is flexible&powerfull enough to emulate the GS? 16 fixed function pixel shaders @ 166MHz wouldn't be able to do with 48 programable shaders @ 500MHz?
What else am I missing here, and how come the edram isn't as flexible?
It only really takes a few hardware features that one has and the other doesn't to make things fall apart.
For instance, PS2's GS has support for 4bpp and 8bpp paletted textures, which I'm not aware of Xenos supporting. Emulating this either means expanding in a texture cache - which could now blow your eDRAM constraints - or doing it in shaders which can be pretty expensive.
Others here seem to know a lot about GS, so maybe they could give some more examples of where things don't line up. Trying to fit one complex set of special purpose hardware another can be a quite precarious proposition if there isn't some unifying standard that guarantees they do only the same things.
