(Documentation request) Explain the emulator design

[hardBSDk]

I can't find a document explaining how this emulator is designed, based on what I saw on the README of the compatibility list it is a hybrid LLE/HLE emulator.

Each game is mocked to think that it is running on Orbis OS but translated to the host OS, thus there's no need for hardware emulation (which will have much lower overhead because PS4 uses a PC architecture).

[Dr-42]

Does anyone know where actual main render loop is?

[polybiusproxy]

I believe that the best way of learning a program's flow is by reading its code. Though I can see there's people who still want to know yet don't have enough skill to understand the code, so it's true that it'd be great to have documentation on that. But to sum it up quickly:

1. Main eboot (game executable) is loaded.
2. System libraries are loaded.
3. Start running the eboot. We lose 'control' of the thread now.
4. The guest runs its code. (e.g. load game assets, initialize systems, game UI, etc.)
5. The guest calls system functions (they can be LLE or HLE).
6. The guest starts sending GPU command buffers.
7. The emulator receives said command buffers and does proper rendering (shader compilation, rendering).
8. Repeat on step 4.

Things worth noting:

• We don't emulate the CPU - any guest code is executed natively, which is why the emulator is currently only available for x86 CPUs (excluding ARM Mac computers with the Rosetta recompiler).
• We act as a compatibility layer by doing a reimplementation of the system libraries.
• Certain system libraries run with LLE, so we're part LLE and HLE.
• We're also an emulator since the GPU has to be fully emulated. The GPU is the only portion of the PS4's hardware that is emulated.

[...] Where is the render loop at?

The emulator does not have a render loop. We do rendering when the guest wants to. The guest fills command buffers to send to the GPU. We also fill command buffers with a reimplementation of the GnmDriver system library [1].

Once the game finishes filling the GPU command buffers, it submits them and they're received by the emulator. This is where the GPU emulation starts. It works by going over the submitted PM4 packets; these can reset, set GPU registers, make draw and dispatch calls, move data over DMA, and so on.

Once a draw call packet is encountered, the graphics pipeline is compiled (if needed), and a Vulkan draw call is done. If the guest does not submit command buffers, none of the above happens.

You can find the relevant code here:

• https://github.com/shadps4-emu/shadPS4/tree/main/src/video_core/amdgpu
• https://github.com/shadps4-emu/shadPS4/tree/main/src/video_core/renderer_vulkan

I hope I explained everything you wanted to know. Let me know if you have any other questions.

[1] Gnm is the name of the PS4's graphics API. It is similar to DirectX 11.

[hardBSDk]

@polybiusproxy Thanks a lot for your answer!

Interesting, the emulator also translate the Gnm API calls to Vulkan.

[hardBSDk]

@polybiusproxy Does the emulator just translate the Orbis OS system calls or parts of the kernel are implemented or translated?

[polybiusproxy]

Both system library calls and the kernel are reimplemented.

[Dr-42]

Thanks. This is quite helpful.

[hgh32]

@polybiusproxy Do you know about buffer memory alignment? I just know it's related to hardware and vulkan