Double regression with God of War: Collection [BCUS98229]

[dio-gh]

There was a performance regression I noticed with GoW2 (in GoW:C) on my desktop months ago, but after hours of testing, I think, I found a double regression.

Regression 1:

After careful build bisecting I found out, that #4505 was the PR that caused the heavy performance regression that made me research this issue. That build (0.0.5-6733) caused GoW2 to slow down to a point of no return, with the cutscene playing out so slowly, that I basically couldn't go past it. It went from 25-30 fps, with some audio crackling to 1 fps and no audio, just crackling.

I thought being such an old build, it must have got already resolved since then. But that wasn't exactly the case.

Regression 2:

Like any noob trying to bisect, I started with the current master (0.0.5-7175 in the time of writing). But the symptoms were quite different from what I expected - GoW2 didn't even launch. As a matter of fact, not only GoW2 haven't launched, but GoW1 either. They both crashed with either a white screen, and later a black screen showing only.

After tackling the first regression, I thought I shouldn't leave this uninvestigated. After some trial and error I arrived at #4876, which happened to be the build (0.0.5-7096) that broke these games completely. So there we go. Or are we?

The thing is, my dump of GoW:C is.. uhh.. corrupted. So what I'd ask first, is someone with a valid dump to verify these issues, please. I'll try and get my hands on a valid dump until then, and if anyone has it, I'm available on Discord.

My desktop contains an i5-4440 (no tsx, 4c4t), 8 gigs of ram and an old HD7770 gpu, with 1 gigs of vram. OS is Windows 8.1 Pro (x64, build 9600). Default settings were used throughout my testing, though I did try messing around with settings at master to no avail.

Edit: Turning off async shader compiler seems to fix the second regression. Thank to Hula for notifying me about this. The first regression still remains.

Log from latest master (0.0.5-7175) with everything on default, but async turned off (up till the beginning of the first prerendered cutscene from GoW2):
RPCS3.log.gz

RRC capture and logs from Vulkan, at master, from the same scene. This time, async has been turned back on, and ofc strict rendering is on as well. No performance changes, Vulkan looks more graphically accurate than OpenGL, but otherwise behaves the same. Both go past regression 2 if they have an inital shader cache built up, but both tank still during cutscene (can't reach ingame).
BCUS98229_20180812224038_capture.zip
RPCS3.log.gz

Edit 2:
So, after 2 hours of testing, I managed to dig deeper somewhat. After switching over to Vulkan, I tried out SPU LLVM - with great success. With SPU Giga, it powered through the opening cutscene with some major dips and minimal crackling, then presented me with the fastest ingame state the game has ever showed on me on my desktop (between 35-45, with some hitches).

After that, I tried out the rest of the SPU settings, Mega and Safe with LLVM. Both worked about the same, with Safe maybe having the least crackling and the most stable, albeit a bit lower performance compared to the others. This might also have been due to the cache buildup. Do note that strict rendering remained on throughout by mistake.

With these infos in hand, I tried again with ASMJIT for one last time, thinking it would fail. But that wasn't the case at all - it worked its way through the cutscenes with both SPU Giga and SPU Safe, just as LLVM. I thought this might have been due to the fact, that LLVM has already built up the SPU cache by then. To test this theory, I deleted the SPU cache, and then later both the SPU and the Shaders cache - none of them resulting in the same behavior as described in regression 1. This remained true after turning strict rendering off.

What was even more interesting, is that even after deleting the shaders cache, the game (gow2) still booted up. Right after regression 2 I mentioned, that turning off async shaders made the regression 2 disappear - but now it worked perfectly, even with no cache in store.

Bottom line is, somehow due to all this testing, I managed to make both regressions disappear completely, even with all caches cleared. This is the point, where I officially don't have the slightest clue on what's going on anymore. One thing to note, is that with 4c4t, 1 spu threads seems to be the only working option with this game. Nor "auto", nor any other setting works. Interesting stuff all around.

Edit 3: After a random idea I had, I tried ASMJIT and LLVM with spu thread auto. Turns out, if I set spu threads to anything but 1, I can't go past the cutscene (regression 1 occurs). This means that in #4505 some changes were made to this option, seemingly breaking the game for me. It still doesnt explain regression 2 however, nor the whole tirade, so more testing is probably needed.

With a clean install, regression 2 is easily reproduceable. Here are the logs about it, with both spu threads auto and spu threads 1:
RPCS3_whitescreen_crash_spu_auto.zip
RPCS3_whitescreen_crash_spu_1.zip

[kd-11]

This game has always suffered from race conditions that cause freezing. I could go into technical details here but I should clarify - no, that PR did not change SPU behavior at all. It however made RSX much faster. This is why you're seeing random deadlocks. Ofc everyone's setup will be affected differently due to the nature of this condition, with the only 'real' solution being to make everything slow again so that they don't computationally drift apart. Generally, the faster the SPU emulation you have (SPU LLVM and enough physical resources to avoid thread swap, 8+ threads) the more stable it behaves. Setting SPU threads to 1 greatly reduces the amount of OS scheduler pre-emption which leads me to believe you have an older quad with no HT.

[dio-gh]

Closing. The game's status has changed a lot since this test, so I'll open a different ticket if necessary when I'll have time to investigate.