Technical estimation of difficulty to emulate PS4 vs newer consoles

[LifeIsStrange]

I am not an expert but like many i would have expected the PS4 to be easier to emulate than the PS3 since its hardware is much closer to PC.
As for the CPU you can just use the host x86 cpu through a hypervisor e.g haxm which is what orbital is doing. Or by using e.g. Box64

The remaining complexities would be:
Low level differences vs a regular pc architecture
And notably, a GPU API mismatch (the PS4 expect raw GCN assembly??)
However I think it would be a mistake to not seriously ask yourself whether the PS5 would be actually easier to emulate.
It's still x86 and an updated GCN but it might have less lower level differences vs a regular pc architecture and might have less of a GPU api mismatch.

But my neophyte opinion would be that the Xbox series X/S would be the easiest platform to emulate.
Since it's still a x86, updated GCN BUT If I recall correctly, xbox serie X games are coded in direct X 12, which is much easier to map to vulkan and crucially is natively supported on windows. The OSes would also match.

Unrelated, if the GCN to spirv mapping is a ley difficulty, couldn't you offload GCN assembly directly to the host GPU if the host GPU is an AMD gpu?
The switch emulator Yuzu supports this for Nvidia gpus.

BTW I really think you should do a patreon, even if it's just currently a part time project, it could become big!

[Masamune3210]

There are quite a few major differences between Desktop Windows and GameOS which is what runs while playing a game on the One/Series consoles.

We really don't know enough about the ps5 to know how close to a PC it is or not. The ps4 was thought to be really close to a PC at first as well but porting Linux to it showed just how wrong that statement can be

[Fox2Code]

For now the project look like it took a bit the Wine path, where it's neither a emulator or container but a translation layer.

This means PS4 games are in the same memory space than system libraries.

On one side it reduce the overhead and latency of emulation or virtualization, but it also make compatibility more limited.

[Inori]

where it's neither a emulator or container but a translation layer.

well, it now looks like an emulator a bit 😋

[Fox2Code]

I think since Windows doesn't allow to catch syscall it's necessary,
but on linux you could use user syscall dispatch or ptrace + seccomp.

User syscall dispatch is a recent linux kernel feature so some older linux do not have it.
ptrace and seccomp are older so support more older kernels but is much slower.

Wine use ptrace + seccomp to intercept Windows programs syscalls

For non-linux users this is what each Linux specific word means:
Linux -> Open source kernel used in many projects like Android
Wine -> Software to run Windows programs on Linux and MacOS.
syscall -> System call, special instruction to talk directly to the kernel.
user syscall dispatch -> Linux feature to allow user space to handle syscalls
ptrace -> syscall to debug a process and/or it's syscalls
seccomp -> Linux feature to allow to filter syscalls

[Inori]

syscall is not the problem, we HLE most api, converting it to host OS api like wine does.
The problem is we have to emulate VRAM since PS4 uses an unified memory architecture. This is the major difference compared to wine.

[Inori]

PS5 would be actually easier to emulate

Not sure for PS5, haven't dig in too much for that, just guess it's pretty similar to PS4, and if this is true, these's not much difference about the things to do.

The switch emulator Yuzu supports this for Nvidia gpus.

I thought it is even impossible before you tell me that Yuzu support it, maybe we can have a try in the future.

[LifeIsStrange]

about yuzu support for assembly its
https://en.wikipedia.org/wiki/ARB_assembly_language which is not really supported on AMD
As for reusing AMD GCN assembly I have no idea, maybe https://github.com/SunsetQuest/Asm4GCN it seems like a topic nobody knows much about :m
or
https://rocmdocs.amd.com/en/latest/Programming_Guides/gcn-assembler.html
https://gpuopen.com/learn/amd-gcn-assembly-cross-lane-operations/
https://www.codeproject.com/Articles/872477/Assembler-for-AMD-s-GCN-GPU
then there is the LLVM AMDGPU backend https://llvm.org/docs/AMDGPUUsage.html
maybe CodeXL can help with development

[VelocityRa]

Unrelated, if the GCN to spirv mapping is a ley difficulty, couldn't you offload GCN assembly directly to the host GPU if the host GPU is an AMD gpu?
The switch emulator Yuzu supports this for Nvidia gpus.

Source? I really doubt that's the case.
Maybe you're confusing its GLASM backend with this? Because in that case it's not "direct" at all as far as I can tell, it still has to be translated.

[Masamune3210]

Yeah, that's GLASM, and no, it's basically assembly but for the GPU and only works on Nvidia's GPU because AMD doesn't know how to follow a standard to save their life

[Inori]

So this is not a real issue, I shall close it.

[Inori]

Well, I convert this issue to discussion for the first try. 😺

[LifeIsStrange]

Potentially related to the idea of supporting GCN shaders/assembly directly on AMD gpus:
https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_AMD_gcn_shader.html

[Inori]

This extension exposes miscellaneous features of the AMD "Graphics Core Next" shader architecture. This includes cube map query functions and a functionality to query the elapsed shader core time.
This extension is not related to execute GCN instructions on GPU, and even if we can, the shader binary for PS4 game is compiled against one special AMD GPU, there will be compatible problems on other desktop GPUs, besides, we have to emulate VRAM either.
Things are not as easy as it first comes to people's mind.

[VelocityRa]

Things are not as easy as it first comes to people's mind.

If I could count the times some clueless rando has suggested in RPCS3's #development channel to "use the GPU for emulating SPUs"... 😅 As if the super smart people working on this wouldn't have considered it.

[Masamune3210]

Unified memory is always a pain for emulators, maybe go look at others to see how they are handling it? It won't be directly usable since the system is different but could give some ideas

[Inori]

I already came out a way to deal with it.

[chaysf]

you aware of this project?

https://github.com/InoriRus/Kyty

[Inori]

awesome project

[Inori]

It seems the way he emulate GPU memory is the same as I did two years ago.
I just found it too difficult to complete so I gave up and instead turn to a new way.

[LifeIsStrange]

@InoriRus friendly ping, any opinion on the topic ?
BTW It's a mind-blowing coincidence that you have both Inori in ur name.

[chaysf]

Always thought @InoriRus was @Inori

Great minds think alike I guess.

[InoriRus]

Always thought @InoriRus was @Inori

Great minds think alike I guess.

Or maybe we are both FFX fans

[LifeIsStrange]

@Inori @InoriRus
What about leveraging the official PS4 compiler from Sony?
https://www.phoronix.com/scan.php?page=news_item&px=PlayStation-4-LLVM-Landing
https://www.phoronix.com/scan.php?page=news_item&px=Sony-PS5-LLVM-Upstream-Start

[VelocityRa]

1) I guarantee you they're already aware of obvious things like that
2) They can't publicly say anything implying they have used it or will use it, that would be illegal
3) No open-source project could rely on official/NDA'd tools like that long-term, for the same reason as 2.

[LifeIsStrange]

about 2 and 3 I strongly disagree, this is merged in stable LLVM code, BSD licensed so it's perfectly 100% legal

[VelocityRa]

My bad, I completely misread those article titles.

I still doubt it's of use. There won't be any Orbis OS APIs exposed. The rest (ie. CPU behavior like the AMD extensions) is already publicly documented iirc. So it's not like this can be used to legally write any interesting homebrew/hw tests.

Also, for reasons that I can't say here, this is not currently necessary anyway so this is kind of pointless.