735
No PS3 backwards compatibility
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 Jul 2024
735 points (97.8% liked)
Memes
51013 readers
1403 users here now
Rules:
- Be civil and nice.
- Try not to excessively repost, as a rule of thumb, wait at least 2 months to do it if you have to.
founded 6 years ago
MODERATORS
It is hard. PS3 has incredibly specialized hardware. Even game developers had trouble making games for it at the time because it’s so arcane.
AFAIK, the documentation isn’t the main problem. I’m pretty sure PS3 is quite well understood.
The problem is how to translate the code to a typical X86 architecture. PS3’s uses a very different architecture with a big focus on their own special way on doing parallelism. It’s not an easy translation, and it must be done at great speed.
The work on RPCS3 incredible, but it took them more than a decade of optimizations to get where they are now. Wii U emulation got figured out relatively quickly in comparison, even if it uses similar specs to PS3.
The Wii U was just a souped up Wii so of course the emulation scene had a Wii U emulator in no time.
Having worked (as a designer, not an engineer) on a PS3 launch tile, this post also aligns with my understanding.
Just rewrite it in haskell (or Fold)! Problem solved :)
They probably have a bunch of developers like me: Dafuq did I do yesterday? 😵💫
Recent crowdstrike problem be like
There can be a lot of subtle changes going from one uarch to another.
Eg, C/C++ for x64 and ARM both use a coprocessor register to store the pointer to thread-local storage. On x64, you can offset that address and read it from memory as an atomic operation. On ARM, you need to first load it into a core register, then you can read the address with offset from memory. This makes accessing thread-local memory on ARM more complicated to do in a thread safe manner than on x64 because you need to be sure you don't get pre-empted between those two instructions or one thread can end up with another's thread-local memory pointer. Some details might be off, it's been a while since I dealt with this issue. I think there was another thing that had to line up perfectly for the bug to happen (like have it happen during a user-mode context switch).
And that's an example for two more similar uarchs. I'm not familiar with cell but I understand it to be a lot more different than x64 vs ARM. Sure, they've got all the documentation and probably still even have the collective expertise such that everything is known by at least someone without needing to look it up, but those individuals might not have that same understanding on the x64 side of things to see the pitfalls before running into them.
And even once they experience various bugs, they still need to be debugged to figure out what's going on, and there's potential that the solution isn't even possible in the paradigm used to design whatever go-between system they were currently working on.
They are both Turing complete, so there is a 1:1 functional equivalence between them (ie, anything one can do, the other can). But it doesn't mean both will be able to do it as fast as the other. An obvious example of this is desktops with 2024 hardware and desktops with 1990 hardware also have that 1:1 functional equivalence, but the more recent machines run circles around the older ones.
That's all understandable, for a startup or young company. But this is Sony a multi-billion dollar electronics company with many MANY released devices and software projects under its belt.
If they had taken things seriously, invested the proper funding and pulled the appropriate personnel they would have no problems getting something out that can beat RPCS3 in a year tops.
They tried to just slap something together as (what someone around here commented a while back) a minimum value add product and shove it out the door. Any claims of "It's just too hard" they try to make is nothing but cover AFAIC now that people are starting to call them out on it
"It's too hard" really means "we don't think the benefit we'd gain is worth the resources and effort it would take to get there".
For profit corporations should not be trusted to preserve out culture. They would happily delete everything it if made then 1 dollar
I've worked at companies where the documentation was either non-existent, not digitized, or very poor in quality. Add 10+ years to that when nobody is left at the company who worked on the original project and it can cause this exact level of frustration.
Most of the games I've played on RPCS3 look way better and run much smoother than how they did on the console itself. And no long wait times to load into the console OS save menuz saving was nearly instant. So good.
They pay someone handsomely to make excuses for them.
Yes it is hard, and that was their damn fault. I can’t believe they expected developers to have to program which processors take which loads with such granularity. Unbelievably stupid.
Was the idea to improve performance?
Yes, when used properly it did out perform the competition.
Yes but the modest improvement in output over the 360 was clearly not worth it
It is, and it does provide improved performance at the expense of complexity. Both India and the US Air Force actually used clusters of PS3s to create supercomputers.
https://en.m.wikipedia.org/wiki/Cell_(processor) has some more details as well
I don't think it being hard is really the issue. Sony is a billion dollar multi-national corporation and they don't get any benefit of the doubt whatsoever. Is it hard? Maybe it is, but maybe they should have thought of what they were going to do in the future when they were designing this. As was pointed out elsewhere, volunteers making an open source emulator are managing it so Sony not wanting to, or being unable to, isn't an excuse.