mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-04-25 07:46:01 +03:00
[GH-ISSUE #1512] (Documentation request) Explain the emulator design #512
Labels
No labels
Bloodborne
bug
contributor wanted
documentation
enhancement
frontend
good first issue
help wanted
linux
pull-request
question
release
verification progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shadPS4#512
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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).
@Dr-42 commented on GitHub (Nov 18, 2024):
Does anyone know where actual main render loop is?
@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:
Things worth noting:
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.
@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.
@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?
@polybiusproxy commented on GitHub (Nov 21, 2024):
Both system library calls and the kernel are reimplemented.
@Dr-42 commented on GitHub (Nov 21, 2024):
Thanks. This is quite helpful.
@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
@polybiusproxy commented on GitHub (Dec 3, 2024):
I don't know much about that, sorry.
@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