Okay... so you need to take a step back. Sorry but I do not think you know what you are trying to undertake.
There are a TON of things that you would need in order to get (3D accelerated) commercial games to work, and it's probably just not possible yet with the information we have on the PlayStation 4 AMD APU and other weird chipsets.
1. There is no 3D accelerator on the market that acts exactly like the PS4 APU - it is a heavily modified Jaguar+Radeon APU+chipset, with no 'on-die' north/southbridge, or IRC timing components you'd find in a normal PC (). You will have to be translating the weird GL / transfer operations from the game code into the emulated GPU, and then into something like native OpenGL on the host, which I don't think is fully understood yet. Assuming we even have fast enough memory/bus to "emulate" this process yet.
2. You'll to create a process that virutalises the weird IOMMU bridge between PCI-Express and the APU, which even the PS4 Linux developers do not fully understand ()
3. There are the "Onion" and "Garlic" buses between the memory and the GPU which are non-standard and operate at something stupid like 180gibs. There is nothing that fast yet on x86-xx commercial PCs - you'd probably have to scrape and load most of the required graphic assets, for the specific scene, into memory, of which most people/devices won't have enough.
4. Security. Running straight from an unmodified PS4 ISO is probably impossible - there's a lot going on here. There is a security co-processor on the APU die that is not fully understood yet. The game is expecting when it "asks" to execute something, that the Orbis OS is going to facilitate decrypting and verifying the binary (or section thereof), and then jumping to it. You can decrypt the whole ISO, but then you are going to need to patch on-the-fly all of these checks, such that the game believes it is running on real hardware, and running correctly. This is not easy and takes years to even get some kind of display on the screen. You will also be having to manage writeable or executable pages in the same way that the PS4 does, which is likely to also be extremely custom and emulating it will drop performance. If you want to do this 'natively', you would probably be designing your emulator to just ignore this, however most modern OS will not allow it - so to even get the emulator to run, you'd be asking users to disable OS security features which might not even be possible.
5. The OS and subsystems. The game executable is going to be constantly trying to read license info and anti-piracy, PSN connection, friends list, identity, sockets, devices, other stuff. You have to trap and emulate returns for all of this, and reversing these calls is mostly just trial and error with lots of luck mixed in.
6. Instruction set. The PS4 is a "off shelf" (in quotes) AMD Jaguar CPU, but there is bound to be a bunch of extra instructions that Sony asked for, probably for performance and security functions, that will just lob illegal_instruction exceptions and catch fire. You'd need to patch all of these out on-the-fly with equivalent routines; this may DUNK performance as well, depending on what else is going on.
If you have never written an actual "emulator" of anything before, definitely start with trying to emulate some pico gpio processor, not a massive commercial game console on which thousands of people spent years producing.
