Emulating a PS3 is significantly harder than emulating a PS4, since on the PS3 you need to convert from the Cell architecture, whereas the PS4 is already x86.
I think this too. My perception of the PS4 is it's just a PC in a box running FreeBSD (or something). I don't think there is any custom architecture at all. Much like a steam deck, which can already run some first party PS4 games just fine (e.g. Death Stranding). Would any emulation even be required?
They have custom graphics APIs (and semi custom GPUs) which makes graphics translation one of the hardest parts.
The graphics systems also assume shared memory which is not a given elsewhere.
There are sometimes also some extra CPU instructions if it benefits the console that may not be prevalent, and require some translation.
And it’s even more different when you get to the PS5 era where the systems have some very critical hardware systems like kraken decompression and direct storage which don’t have super prevalent equivalents.
>And it’s even more different when you get to the PS5 era
Do you think a PS4 emulator should be 90% of the way to a PS5 emulator being that they both use x86, AMD GPU and NVM/X?
ps. I argued with you here[0] about Vulkan on MacOS, and after reading more about graphics APIs and game engines I can say I was wrong about some of what I said eg. "studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes" which after researching, studios do heavily modify Unreal, but they do not seem to touch the rendering APIs. (with some exceptions like here[1]). Also "Adding an extra platform like MacOS [on UE] is not simply clicking a button" which I simply assumed is true but have no evidence for.
I don’t think the PS4 and PS5 are all that similar.
They use very different generations of CPU, and GPU. So shader libraries will be different for the most part. Also custom hardware on top of that for decoding and direct storage access, as well as a fairly updated SDK.
It’ll certainly help because the underlying systems have the same thread of design running through them but I think it’s the same way a 3DS emulator can help with the switch or how Dolphin can’t really do Wii U games. They’re similar but not quite.
And I’m surprised that conversation was remembered :-) thanks for bringing it up.
>They use very different generations of CPU, and GPU. So shader libraries will be different for the most part.
Can you expound on this? Why do the shader libraries change due to new hardware? I get that the compiled shaders would change, but why would the libraries themselves change? The other points I understand.
>I’m surprised that conversation was remembered
I remembered the conversation because I spent some time trying to prove I was right about gamedevs using raw vulkan/directx (they seemingly do not, I was wrong) and then learning more about graphics APIs in general. I realized you were the the one I had had that conversation with because when I searched hn.algolia for Gnm earlier to answer my question elsewhere in this thread your name kept popping up, making roughly the same arguments from that thread I responded to you in.
To your question, consider that console games ship precompiled shader libraries that target the known GPU of that console. This prevents shader compile hitches etc.
So the PS5 is effectively a superset of the PS4, with a significant new set of capabilities. There’s no opportunity to take an intermediate language like Proton etc does to transpile it first.
Main differences would be hardcoded expectations regarding very tight integration between GPU and CPU, and the available memory bandwidth.
PS4 (and PS5, iirc) both use a custom OS built out of FreeBSD with specialized variant of an AMD APU using GDDR memory, plus PS5 got few extra coprocessors for handling things like decompression in line with storage access
Sony also did some really weird stuff with the PS4 to make emulation harder, chiefly among them the PCIe “glue device”, a PCIe device that masquerades as one of 15 (?) different ones, depending on the function needed at that instant. Geohotz has a section on it in his presentation about jailbreaking the PS4.
There are various ways they could be made to care, e.g. wrapping a function call in a macro that expands with some sort of assertion about hardware state. But I'm guessing that if they were told to design emulation counter-measures, it was to defeat hardware emulation and not WINE-style library shimming.
You'd most likely need to run it in a VM and either implement the needed APIs or implement whatever the official OS needs to run (RPCS3 has you download the OS from Sony and implements whatever needed to run, Xenia on the other hand -Xbox360 emulator- reimplements the OS so that you don't need anything from Microsoft).
That's a different problem. I guess emulation devs targeting consoles which originally ran x86 code will not ship arm binaries for a long time. That layer of translation will be left to rosetta 2 and whatever microsoft ships as translation layer.
