It's worth noting that there's another credible PS4 emulator project that's been around for a while: Orbital [1].
I don't bring this up to suggest that GPCS4 isn't important or innovative, but to look at the big picture. Orbital is emulating PS4 at a low level and trying to actually run the PS4 operating system; its first "hype" screenshot was of the recovery mode prompting to push the PS button on the not-yet-emulated controller. Following Orbital, I've felt for a while that there would basically be a two-pronged approach where Orbital enables reverse-engineering and another emulator leverages those insights to enable a higher-performance approach for actually playing games. GPCS4 looks a lot like it could become that other emulator.
Just out of curiosity, is it really still an emulator when the processor architecture is the same as the host machine and all you're really doing is breaking through layers of encryption and lockouts? The ps4 runs on an AMD x86 cpu, would the instruction set not be the same as most PCs?
Not that these aren't still cool projects I'm happy to see being worked on, but I always think of emulators as emulating one type of architecture on top of another.
Maybe I'm wrong about all this, but your comment just made me think of this.
The PS4 isn't a PC at all though. It's missing a bunch of core components, it has different memory maps and instead of a traditional motherboard chipset, it has a separate ARM controller that does crazy stuff.
Checkout the Fail0ver video on porting Linux to the PS4. It's really interesting.
I remember watching that talk and thinking it was interesting but also that the guy was a little harsh on Sony. Sure the engineers at Sony may have done some weird choices in some places, but I think they likely had their reasons for doing things the way that they did. And at the end of the day, Sony delivered a console that works well for its intended purpose.
There is no bright line for when something is or is not an emulator. It's not worth thinking about too much. There is a surprisingly smooth spectrum from "direct emulation of hardware gates" through "full recompilation to the target architecture", with a ton of mixing and matching of all the techniques.
It definitely gets fuzzy. While the CPU family is the same, the overall system architecture is very different. For starters, the PS4 "south bridge" is almost an embedded system in its own right. It's also debatable to what extent shader translation overlaps with "emulation", because there are several different vendor/stack-specific notions of IRs and "precompiled" shaders that don't necessarily map well to the ISA vs. implementation distinctions that exist on CPUs.
Nothing is stopping you from truly emulating a CPU architecture on same architecture, but usually you don't want to for performance reasons (hence paravirtualized drivers and leveraging HW virtualization support).
You might want to for security or other reasons, though.
I think Bochs and DOSBox are examples of x86 emulated on x86.
This is really neat! It's not very frequent that you see this new of a project running commercial games out of the gate.
Chinese universities are helping some of the most gifted students I've seen in years get sunlight here in the West. I can't tell you how many amazing repos I've found that were by students of Chinese universities that come out swinging with impressive projects. I wish this was more a trend in the States, and I have to wonder why it isn't. Possibly because people who speak English fluently are flooded with blog posts and internet forum comments browbeating them into avoiding difficult things?
I know the dev and he isn't actually a student, his GitHub profile was just not updated.
Not to say that there aren't many university students interested in challenging topics like emulator development - I am one myself and know several other students in the emudev scene.
Anyway, university doesn't play a big role for most people, you don't learn many relevant things regarding that there anyway (other than bare essentials).
You learn by doing. Just need to be curious enough to motivate you. That's true for most programming topics, not just emudev.
It could be the law of large numbers too. A large, wealthy society may have a relatively small range of percentage of gifted individuals. Three times as many people: three times as many as gifted people churning out amazing work.
It's not easy to tell, how are they addressing the lack of decryption keys, if at all? I know you can treat a hacked PS4 as a decryption oracle but that's sort of a fundamental limitation to emulation, not having the decryption keys for executables.
Anyway, PS4 emulation isn't very affected by this.
Only thing it would benefit from would be that you'd be able to decrypt the firmware (and therefore run the emulator) without needing a hacked PS4 (like RPCS3 does with PS3 firmware).
Historically most people just pirate the firmware anyway (see: PS1 BIOS) so even there realistically it doesn't affect things that much. I consider this is a long-term, nice-to-have feature.
Still gotta emulate a very modern AMD GPU :)
Just the shader translation (from GCN -> SPIR-V so it can be passed to the host gfx driver) is quite a challenging task actually.
Not to mention the fact that the PS4 has an APU and utilizes Uniform memory access (UMA). A simplified explanation is that both the GPU and CPU can read/write the same memory (with _very_ high bandwidth compared to conventional PCs), which will likely make optimizing high-end games that take advantage of this difficult.
Thanks for that explanation; I read documents about the PS4 arch and those things seemed to be far more mainstream than how you explain it. Any good documents about those details or could I only know this if I was a PS4 (licensed) dev?
On paper it would be possible but at the very least the graphics drivers are going to get in your way (on purpose, for robustness and other reasons) so you'd need to be running like... a custom kernel module or custom graphics driver to do this. It's not safe to let a regular user-mode application do what a PS4 game can do. (The PS4 does security at a hypervisor level instead, and generally your game is not about to steal credit card numbers from another user-mode process on the console like it could on a desktop PC)
Wish I could give up my PS4 and switch to my monster of a gaming PC. Only really looking forward to The Last Of Us 2 and gotta keep it hanging around. Would be sweet if they supported an official emulator where your games work if you already bought the hardware
> where your games work if you already bought the hardware
I think that's called ‘remote play’.
Also the principle with consoles in the first place is dodging the headaches of the PCs' configuration zoo. Emulation, ahem, doesn't fit in with this course.
CPU is just x86-64, so on PC no emulation of that is necessary. More problematic is translation of custom graphics API (Gnm/Gnmx) and shading language (PSSL), but similar feats were done before (DirectX->OpenGL wined3d, DirectX->Vulkan DXVK, etc.) so it should be doable. Game performance might be hurt because they could have assumed that CPU<>GPU transfers are very fast, on PS4 it is UMA with single memory.
Though I wonder how feasible would be trying to pull graphics driver from PS4 firmware and make it to work with Radeon HD7000 series GPU.
PSSL doesn't need to be emulated, it's compiled offline to machine code binaries for the GPU. The DirectX -> OpenGL wined3d backend is similar inspirit, but the bytecode (DXBC) in D3D is a much, much higher level, so better compilation is possible. Untangling machine code into good shading language is not easy.
Additionally, GNM is a lot lower level than even something like Vulkan, and you can pass pointers directly between the CPU and GPU, they share the same memory space. It's this that makes emulating things tricky.
> Though I wonder how feasible would be trying to pull graphics driver from PS4 firmware
There is no "graphics driver", in the traditional sense.
...which makes the job much harder. Shading languages aren't terribly complicated; implementing a compiler from one to native spir-v/whatever is a reasonable task. Translating from one shader bytecode to another is a more involved operation.
The original Xbox is x86 as well, the complex part is emulating the GPU, DSP, etc, which developers sometimes use at a very low level, setting registers, relying on HW quirks, etc (see: xqemu)
Maybe such low-level optimizations are now longer necessary with more powerful consoles, though?
Regarding GPU drivers, that seems quite doable, as the PS4 Linux port uses slightly modified open source drivers, and gets good performance, IIRC.
The way the memory interface works seems like a big barrier. Some games probably don't lean on its true power - the ones I've worked on do not - but a PS4 game can do some truly wild stuff involving GPU/CPU memory sharing, control over memory caching, etc that you can't really do on a desktop PC for various reasons. You can get closer with modern APIs like Vulkan, at least, but I suspect there will always be some subset of PS4 titles that literally cannot function in a typical desktop PC user-mode environment without some truly devious hacks and workarounds.
As far as compute goes though the PS4 is basically just a 64-bit x86 machine with a strong integrated GPU, so the workloads can be adapted to run on desktop hardware.
I don't bring this up to suggest that GPCS4 isn't important or innovative, but to look at the big picture. Orbital is emulating PS4 at a low level and trying to actually run the PS4 operating system; its first "hype" screenshot was of the recovery mode prompting to push the PS button on the not-yet-emulated controller. Following Orbital, I've felt for a while that there would basically be a two-pronged approach where Orbital enables reverse-engineering and another emulator leverages those insights to enable a higher-performance approach for actually playing games. GPCS4 looks a lot like it could become that other emulator.
[1] https://github.com/AlexAltea/orbital