[GH-ISSUE #1512] (Documentation request) Explain the emulator design #512

Closed
opened 2026-02-27 21:06:39 +03:00 by kerem · 9 comments
Owner

Originally created by @hardBSDk on GitHub (Nov 9, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1512

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).

Originally created by @hardBSDk on GitHub (Nov 9, 2024). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1512 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).
kerem 2026-02-27 21:06:39 +03:00
Author
Owner

@Dr-42 commented on GitHub (Nov 18, 2024):

Does anyone know where actual main render loop is?

<!-- gh-comment-id:2481989652 --> @Dr-42 commented on GitHub (Nov 18, 2024): Does anyone know where actual main render loop is?
Author
Owner

@polybiusproxy commented on GitHub (Nov 21, 2024):

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:

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.

<!-- gh-comment-id:2491802808 --> @polybiusproxy commented on GitHub (Nov 21, 2024): 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.
Author
Owner

@hardBSDk commented on GitHub (Nov 21, 2024):

@polybiusproxy Thanks a lot for your answer!

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

<!-- gh-comment-id:2492071361 --> @hardBSDk commented on GitHub (Nov 21, 2024): @polybiusproxy Thanks a lot for your answer! Interesting, the emulator also translate the Gnm API calls to Vulkan.
Author
Owner

@hardBSDk commented on GitHub (Nov 21, 2024):

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

<!-- gh-comment-id:2492079553 --> @hardBSDk commented on GitHub (Nov 21, 2024): @polybiusproxy Does the emulator just translate the Orbis OS system calls or parts of the kernel are implemented or translated?
Author
Owner

@polybiusproxy commented on GitHub (Nov 21, 2024):

Both system library calls and the kernel are reimplemented.

<!-- gh-comment-id:2492089197 --> @polybiusproxy commented on GitHub (Nov 21, 2024): Both system library calls and the kernel are reimplemented.
Author
Owner

@Dr-42 commented on GitHub (Nov 21, 2024):

Thanks. This is quite helpful.

<!-- gh-comment-id:2492338676 --> @Dr-42 commented on GitHub (Nov 21, 2024): Thanks. This is quite helpful.
Author
Owner

@hgh32 commented on GitHub (Nov 24, 2024):

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

<!-- gh-comment-id:2496040234 --> @hgh32 commented on GitHub (Nov 24, 2024): @polybiusproxy Do you know about buffer memory alignment? I just know it's related to hardware and vulkan
Author
Owner

@polybiusproxy commented on GitHub (Dec 3, 2024):

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

I don't know much about that, sorry.

<!-- gh-comment-id:2515546073 --> @polybiusproxy commented on GitHub (Dec 3, 2024): > @polybiusproxy Do you know about buffer memory alignment? I just know it's related to hardware and vulkan I don't know much about that, sorry.
Author
Owner

@Hermiten commented on GitHub (Dec 31, 2024):

I copy paste this message of Poly on the wiki.
https://github.com/shadps4-emu/shadPS4/wiki/VI.-Emulator-Design-%5BDevs%5D
We will improve it in the future

Thanks you

<!-- gh-comment-id:2566264841 --> @Hermiten commented on GitHub (Dec 31, 2024): I copy paste this message of Poly on the wiki. https://github.com/shadps4-emu/shadPS4/wiki/VI.-Emulator-Design-%5BDevs%5D We will improve it in the future Thanks you
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/shadPS4#512
No description provided.