09-15-2016, 04:49 PM (This post was last modified: 08-03-2017, 08:45 PM by ssshadow.)
Now works on master versions, download from rpcs3.net/download and ignore any and all links to strange hacked builds etc.
Optimal settings for Persona 5 are as follows: PPU and SPU recompiler, Vulkan renderer. 1 or 2 or 3 preferred SPU threads depending on your CPU (try all three), SPU loop detection must be enabled, and fps limit should be off. If you see broken shadows, turn on invalidate cache every frame.
Asus N55SF, i7-2670QM (~2,8 ghz under typical load), GeForce GT 555M (only OpenGL)
(09-15-2016, 04:49 PM)ssshadow Wrote: Of course it doesn't work.
That said, since this is quite literally the last meaningful PS3 game to ever be released and Atlus are being fanboys or someshit and not releasing on Steam I am making this thread so no one has to waste time trying.
Rest assured, the day it starts to work (or maybe the day after) I will update this thread. It's probably going to be quite some time though...
So with the info that you gave me, I managed to get to a blank gray screen, but it shows up with an STD:RuntimeError (F {PPU[0x70000000] Thread (main_thread) [0x00b49400]} class std::runtime_error thrown: Stack overflow (size=0x8, align=0x4, SP=0x2034b8a0, stack=*0xd0000000)
(in file C:\rpcs3\rpcs3\Emu\Cell\PPUThread.cpp:410)
)
01-08-2017, 05:27 PM (This post was last modified: 02-15-2017, 11:16 PM by ssshadow.)
I got the game to "work" with a small hack, basically just ignore an exception and continue. The game can hang at random at any time and as you can see in the video I was quick to get past the main menu (with proper looking 3D graphics!).
You can sadly not skip the video that plays after starting a new game, the fade out effect causes some RSX error. Therefore each try at going in game will take about 8 minutes. And the LLVM recompiler doesn't work. But it can go in game, even for just a few seconds as seen in the screenshot below. A faster computer would probably help.
Use OpenGL. Vulkan looks worse than OpenGL and DX12 doesn't work at all, it will fail when reaching the main menu.
(Someone please explain the rationale behind that if-condition, the contents of gpr1 is a much lower address than stack_addr but the game runs regardless... This error happens right when “CRI FS File Access 0” is created, so it's not something unimportant we are ignoring here. Edit: It actually also happens for like 10 other threads too...)
Asus N55SF, i7-2670QM (~2,8 ghz under typical load), GeForce GT 555M (only OpenGL)
for rpcs3 indicate in error in LOG , and rpcs3 indicate this error for boot, after boot have no error
Quote:E {PPU[0x70000000] Thread (main_thread) [0x00b48a50]} PPU: Stack overflow (size=0x8, align=0x4, SP=0x2034c360, stack=*0xd0000000)
(in file Emu\Cell\PPUThread.cpp:411)
E {PPU[0x70000000] Thread (main_thread) [0x00b48a50]} PPU: Stack overflow (size=0x8, align=0x4, SP=0x2034c360, stack=*0xd0000000)
(in file Emu\Cell\PPUThread.cpp:411)
E {PPU[0x70000000] Thread (main_thread) [0x00b48a50]} PPU: Stack overflow (size=0x8, align=0x4, SP=0x2034c120, stack=*0xd0000000)
(in file Emu\Cell\PPUThread.cpp:411)
Upload you Log Here :
PC spec:
Windows 10 PRO X64 Insider 16.232
Amd Ryzen 1700X @3.8 ghz
MSI Core Frozr L
16 go Corsair Vengeance LPX PC4-25600 (3200MHz)
MSI GTX 1080 Gaming X 8G
MSI X370 Gaming Pro Carbon
500 Go SSD Samsung 960 EVO M.2
01-09-2017, 06:37 PM (This post was last modified: 01-09-2017, 06:40 PM by ssshadow.)
(01-09-2017, 06:17 PM)kd-11 Wrote: Interesting find. I wonder what the CPU disassembly around this instruction looks like; might explain the check failing.
I don't know enough to understand why that check is there, there is probably some kind of assumption but it doesn't seem right. The check is run right after creating a new thread, and look how many times it "fails", and yet the game runs... Maybe it is some kind of weird edge case or something, I might have a look later.
01-11-2017, 11:22 AM (This post was last modified: 01-11-2017, 11:39 AM by kd-11.)
(01-09-2017, 06:37 PM)ssshadow Wrote:
(01-09-2017, 06:17 PM)kd-11 Wrote: Interesting find. I wonder what the CPU disassembly around this instruction looks like; might explain the check failing.
I don't know enough to understand why that check is there, there is probably some kind of assumption but it doesn't seem right. The check is run right after creating a new thread, and look how many times it "fails", and yet the game runs... Maybe it is some kind of weird edge case or something, I might have a look later.
Looking at ppu_thread, it seems that check should be removed, or at most just throw a pessimistic warning. I dont think the PPU has a requirement that r1 cannot be set to another target location by the calling thread before performing a push. The faulting addresses also seem to indicate that subsequent threads are all writing to some sequential memory location using a push and that does not seem random to me. Our implementation assumes that the stack frame shall not be changed by the application, but clearly this still happens and I'm guessing the real hardware doesn't care as long as we dont fault on access. This check ought to be moved to the page fault handler IMO and a guard page inserted to properly detect stack overflow, but CPU guys are better suited for this kind of task than I am. Unfortunately I have too much on my plate at the moment, otherwise this could've been a fun challenge.
By the way, an easier way to check for stack overflow without complicating design would be to check if r1 straddles the stack boundary instead of merely doing a check like this. Simplified:
if (old_r1 >= stack_addr && new_r1 < stack_addr) then except;
else
do the push;
This IMO is alot easier to implement than the full implementation idea I mentioned above.