PlayStation 3 emulator RPCS3 gets 75% of all games playable on PC
www.gamingonlinux.com
The incredible open source PlayStation 3 emulator RPCS3 just reached an impressive milestone for getting more games working on PC.
  • 🇨🇦 tunetardis@piefed.caEnglish
    42·
    1 day ago

    That’s impressive.

    At my work, we had these cell processor-based blade servers for a while. Basically the same chips as in a PS3 except they could handle double-precision floats. We wanted to use them for scientific modelling, but gave up eventually. They were such a bitch to program! I can only imagine emulating them must’ve been a nightmare.

      • 🇨🇦 tunetardis@piefed.caEnglish
        4·
        9 hours ago

        I guess you could say the Cell was as an 8-core CPU (well, 9, if you include the PowerPC in the middle) at a time when such things were unheard of, at least in the consumer space. So the theoretical performance if you could max out all those cores was through the roof. I have no doubt that’s what drew Sony to them for their next gen console.

        But whereas all the cores of a modern 8-core chip can access the same RAM, in the Cell, only the PowerPC could access the main memory and each core had its own dedicated internal RAM, meaning you had to load both code and data into all the cores laboriously yourself using asynchronous DMA requests before executing the code, and then sync the results back using more DMA. It was a bit like GPU programming, I suppose, though within the cores, it felt more like a CPU in terms of the instruction set and what not, so kind of a hybrid approach I guess?

        • Buddahriffic@lemmy.worldEnglish
          2·
          7 hours ago

          That sounds like something that might have made it easier to emulate, since on x64 the memory management could be simplified. Though that kind of cache control can lead to very high performance if the working set of data fits into that cache that x64 might have trouble keeping up with.

          • 🇨🇦 tunetardis@piefed.caEnglish
            2·
            6 hours ago

            Yeah, you know, that’s a good way of looking at it. It’s like each core could only access its own cache memory, and all the syncing to main RAM had to be done painstakingly in software. That would be a hardware function in any modern architecture. I can’t remember how big the caches were. I think they were bigger than a typical L1 at least, but not huge.

            Anyway, it was not too horrible if you were just walking through an array sequentially applying some operation to it, but when you had to jump around memory, it became an absolute nightmare! Uuuugh…it’s all coming back to me now why we got nowhere with it.

            • Buddahriffic@lemmy.worldEnglish
              2·
              6 hours ago

              That central core must have gotten really busy managing the memory if several cores were each jumping around a lot. Did it have to do other things also or was it just fulfilling memory requests?

              • 🇨🇦 tunetardis@piefed.caEnglish
                2·
                6 hours ago

                Oh yeah! I mean to be fair, it was a full-fledged PowerPC single core in its own right. I’m pretty sure that generation had AltiVec (simd instructions), so you could theoretically do some number-crunching on it as well, but it had plenty to do already with managing memory I/O. And actually also network I/O for us, since I worked a bit on trying to combine the resources of more than one blade. But man, it just devolved into a giant mess in the end! I think I still have some PTSD from it :P

                • Buddahriffic@lemmy.worldEnglish
                  2·
                  6 hours ago

                  Were you generating dynamic instructions based on what the cores were doing or was it all statically programmed such that the PowerPC core had to be running very specific code that went along with the specific code running on each worker core?

                  That first one might have been very scalable, though I have a feeling either one would be a nightmare to actually write and hell to debug.

                  • 🇨🇦 tunetardis@piefed.caEnglish
                    2·
                    5 hours ago

                    Oh I never got that far. It was all static. I supposed if I had kept plugging away it, I might’ve reinvented a 64-bit OpenCL eventually, but you have to understand the uphill climb it all was. Like I was shocked to discover at one point that while you could compile a 64-bit executable, the malloc library function was still only 32-bit! I bitched about this to IBM tech support, and they said well you could write your own malloc using mmap. I mean yikes!

        • BlackLaZoR@lemmy.worldEnglish
          2·
          9 hours ago

          Fascinating insight.

          It was a bit like GPU programming,

          Don’t remember where I’ve read this but supposedly SONY wanted it to be part of their geometry engine, but ultimately had to cut down the costs and use Nvidia GPU instead. So maybe that analogy isn’t that far off

      • 🇨🇦 tunetardis@piefed.caEnglish
        23·
        1 day ago

        It’s a small company that does mineral surveying, but we’ve done a lot of R&D in the past that ranged from designing our own survey instrumentation to writing geophysical modelling software. The Cell thing was for the latter.

        IIRC the Cell processor was built around an IBM PowerPC, but that wasn’t meant to do all the heavy lifting. Rather, it was supposed to be farmed out to these other processing nodes (I forget what they were called), almost like using a GPU for general computation. Now, the IBM consultant sold us on the Cell, saying they had an OpenCL library that would make all this much easier and hide the hardware details. LOL!

        First of all, it was a 32-bit library. Maybe fine for a 32-bit console like the PS3, but our blades had 16 GB of RAM and it wasn’t going to cut it. So I had to dig into the guts of the architecture to get anything usable and, long story short, a summer went by and I had little to show for my efforts.

        Years later, we eventually got the program running on Threadrippers and that worked out much better!