4 ms·

PCSX3 exists, now, and while I understand the underlying complexities of the PS2’s architecture, I am very curious about the challenges, in particular, of PS3 e

PCSX3 exists, now, and while I understand the underlying complexities of the PS2’s architecture, I am very curious about the challenges, in particular, of PS3 emulation, especially with regards to the Cell processor. Anyone with more knowledge that myself with regards to emulation care to chip in? I’d love some insight, or related articles. Saturn emulation has been a fascination of mine for 15-some years.

ac29 7y ago
Are you maybe actually refereeing to RPCS3? If not, check it out. Their progress reports contain a lot of interesting technical details on the PS3 and its emulation: https://rpcs3.net/blog/ https://rpcs3.net/blog/
monocasa 7y ago
So I guess there's a couple levels to emulation where the answer is different in each. For sort of 80/20 compat the PS2 is easier. You can HLE a couple of the processors, the GPU side of things is from the fixed function days, and has a split VRAM like your PC. The PS3 also has a nasty habit of making the SPEs make up for the anemic GPU and what would traditionally be pixel shader post processing tasks. For Dolphin level full compat, IMO the PS3 is easier. The complexity memory subsystem and just plain number of jobs in flight meant that synchronization was very explicit between the components, as you couldn't really get away with "I'm just going to assume some happens before relationship is valid because I counted the requisite number of cycles". So you can rely quite a bit more as an emulator author that the game authors will make their intentions clearer. There's also more legacy in the PS2; the IO processor is itself a full PS1, that's how backwards compat worked. So you're really looking at all the work to make two emulators in one.
ZirconiumX 7y ago
There are three killers here: self-modifying code, synchronisation, and parallelism, all of which are major headaches for a JIT. The PS3 does not have self-modifying PPC code (SCEI forbade it), which means the PPE blob can be compiled ahead-of-time (RPCS3 converts it into LLVM). The SPE data can self-modify, however, but (to my knowledge) does not require extensive synchronisation, therefore each SPE core can be put on a thread. The PS2 code has fairly extensive use of self-modifying code; Naughty Dog in particular will frequently load parts of the executable in and out of memory on both the PS2 main processor (the EE) and the PS1 processor (the IOP), and rely on the synchronisation between these two separate processors to be fairly tight. Trying to make the EE and IOP separate threads running simultaneously breaks this synchronisation, so the EE and IOP have to run on the same thread. Additionally, the PS2 has two vector units; VU0 is associated with the EE (it can be used as a floating-point SIMD unit in the EE instruction stream) and VU1 is associated with the GS [the PS2's GPU, the Graphics Synthesizer] Interface (GIF) (it can directly output primitives to the GS). This means that VU0 needs to run on the same thread that the EE runs on (because there is instruction stream interlocking), and VU1 needs relatively tight synchronisation to the GS (it is feasible to put it on its own thread, but games can be quite picky with timings)
- w0utert 7y ago
  Very interesting, thanks for the writeup! Sony did manage to ship a PS2 emulator that ran on the second-generation PS3 though (1st generation PS3 had actual PS2 hardware inside, but the second generation was software-only emulation if I recall correctly?). Besides knowing exactly about every hardware detail, any idea how they pulled that off on hardware that was much weaker relative to a PS2, compared to a modern PC?
  - jacobush 7y ago
    Not saying this is how, but they could have a white list of games they patched slightly.
  - garaetjjte 7y ago
    It wasn't very accurate, though. https://www.psdevwiki.com/ps3/PS2_Classics_Emulator_Compatibility_List https://www.psdevwiki.com/ps3/PS2_Classics_Emulator_Compatib...
- monocasa 7y ago
  Doesn't the PS3 support the concept of overlays, which is essentially self modifying code from the emulator's perspective?

ac29 7y ago

Are you maybe actually refereeing to RPCS3? If not, check it out. Their progress reports contain a lot of interesting technical details on the PS3 and its emulation: https://rpcs3.net/blog/ https://rpcs3.net/blog/

monocasa 7y ago

So I guess there's a couple levels to emulation where the answer is different in each. For sort of 80/20 compat the PS2 is easier. You can HLE a couple of the processors, the GPU side of things is from the fixed function days, and has a split VRAM like your PC. The PS3 also has a nasty habit of making the SPEs make up for the anemic GPU and what would traditionally be pixel shader post processing tasks. For Dolphin level full compat, IMO the PS3 is easier. The complexity memory subsystem and just plain number of jobs in flight meant that synchronization was very explicit between the components, as you couldn't really get away with "I'm just going to assume some happens before relationship is valid because I counted the requisite number of cycles". So you can rely quite a bit more as an emulator author that the game authors will make their intentions clearer. There's also more legacy in the PS2; the IO processor is itself a full PS1, that's how backwards compat worked. So you're really looking at all the work to make two emulators in one.

ZirconiumX 7y ago

There are three killers here: self-modifying code, synchronisation, and parallelism, all of which are major headaches for a JIT. The PS3 does not have self-modifying PPC code (SCEI forbade it), which means the PPE blob can be compiled ahead-of-time (RPCS3 converts it into LLVM). The SPE data can self-modify, however, but (to my knowledge) does not require extensive synchronisation, therefore each SPE core can be put on a thread. The PS2 code has fairly extensive use of self-modifying code; Naughty Dog in particular will frequently load parts of the executable in and out of memory on both the PS2 main processor (the EE) and the PS1 processor (the IOP), and rely on the synchronisation between these two separate processors to be fairly tight. Trying to make the EE and IOP separate threads running simultaneously breaks this synchronisation, so the EE and IOP have to run on the same thread. Additionally, the PS2 has two vector units; VU0 is associated with the EE (it can be used as a floating-point SIMD unit in the EE instruction stream) and VU1 is associated with the GS [the PS2's GPU, the Graphics Synthesizer] Interface (GIF) (it can directly output primitives to the GS). This means that VU0 needs to run on the same thread that the EE runs on (because there is instruction stream interlocking), and VU1 needs relatively tight synchronisation to the GS (it is feasible to put it on its own thread, but games can be quite picky with timings)

w0utert 7y ago
Very interesting, thanks for the writeup! Sony did manage to ship a PS2 emulator that ran on the second-generation PS3 though (1st generation PS3 had actual PS2 hardware inside, but the second generation was software-only emulation if I recall correctly?). Besides knowing exactly about every hardware detail, any idea how they pulled that off on hardware that was much weaker relative to a PS2, compared to a modern PC?
- jacobush 7y ago
  Not saying this is how, but they could have a white list of games they patched slightly.
- garaetjjte 7y ago
  It wasn't very accurate, though. https://www.psdevwiki.com/ps3/PS2_Classics_Emulator_Compatibility_List https://www.psdevwiki.com/ps3/PS2_Classics_Emulator_Compatib...
monocasa 7y ago
Doesn't the PS3 support the concept of overlays, which is essentially self modifying code from the emulator's perspective?