-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PPU Analyzer/Savestates: Usability improvements, Reduce LLVM compilation of garbage data #14547
Conversation
Pretty much no difference compiling MGS4 (without PPU precompilation). 27.4s (master) vs 27.9s (pr) |
53c4398
to
7a21d95
Compare
ba343cf
to
867a27e
Compare
483cb58
to
bd6e203
Compare
I improved constrainsts further and made it affect only when patches are applied. |
72930e3
to
7101b64
Compare
Fixed. |
And it just hangs there after building the SPU caches. |
Vulkan crash seems unrelated, maybe try again. |
You can open an issue if you catch it again. |
Improve greedy instruction search.
Previously, savestates 99% of the time caused a second, and much longer (!) PPU LLVM compilation in addition to the already existing cache because it is scanning the whole segment 0. This was done in order to support analysis of patches applied within the savestate file on instructions located outside of registered code regions in executable.
Now, why savestates do not simply allow patches to be reused and re-register them instead? because applying patches after boot (on savestates for example) and before boot (normal patches) is not the same operation and may have different and unexpected consequences on farther execution.
The idea here is simply to avoid this and compile segment 0 at all times, so there won't be a second compilation for savestates. In order to avoid compiling garbage data, I added some more constraints in PPU Analayzer.
Please test if PPU LLVM compilation is being signficantly prolonged by this pr and remove previous PPU cache before testing.I improved constrainsts further and made the "anti-optimization" affect only when patches are applied.
So in turn it may actually improve PPU LLVM compilation time when patches are not applied.