PPSSPP: Preliminary report on games with Multithreaded enabled. (a.k.a the return of GE Timing issues with MT on)

[solarmystic]

I haven't seen a catch-all issue report opened yet to discuss the effects of enabling the brand new and experimental Multithreaded (MT) function implemented by @unknownbrackets, so I've decided to take the initiative and report my findings here.

This issue report can be used by others to share their own reports about their own games with MT enabled too.

All settings used are default, with the exception of enabling the Multithreading option, 3x Rendering Resolution and the Speed/VPS display (modified to display actual VPS numbers)

UPDATE:-

In case scrolling through raw data and screenshots are a hassle, here're the results tabulated without the fluff. (updated to reflect the latest [Unknown] fix https://github.com/hrydgard/ppsspp/issues/3127):-

Raw data used to make table:-

Monhun Freedom Unite:-

Internal FPS during FMVs drops ridiculously.(to as low as 9-10FPS)

Internal FPS during gameplay drops from 30 to 20

Monhun 3rd Portable HD:- just hangs after the CAPCOM title screen. Unplayable with MT on.

Tekken 5 DR:- Internal FPS drops from 60 to 20 FPS during gameplay.

Tekken 6 :- Internal FPS drops from 60 to 20 during FMVs and gameplay.

FF VII Crisis Core:-

Playable, and FMVs function at the right speed.. Seems to be one of the few without any issues with MT enabled. Turbo can be enabled without any issues.

Gundam v Gundam Next Plus:-

Internal FPS slowdown during FMVs and title screens from 60 to a ridiculous number (similar symptoms to MHFU)

Internal FPS drops from 60 to 20 FPS.

DO NOT turbo this game in MT mode, it will hang.

The 3rd Birthday:-

Playable as it was before. No regressions, FMVs and gameplay internal FPS are sustained at 30.

As an added bonus, the flickering elements of the HUD and dialog are now fixed(?) when MT is turned on, although there seems to be an added graphical filter applied to the image with MT on.

MT OFF:-

MT ON:-

Final Fantasy Type 0:- Playable just like before, but with a strange white filter at the extremities of the screen.

MT OFF:-

MT ON:-

(I seem to be noticing a trend here)

Danganronpa:-

Internal FPS at the main menu drops below 60 to a variable number (50-60)

Actual gameplay is unaffected, and using Read Framebuffers to Memory to enable object detection for Investigation mode works as expected. Internal FPS during gameplay remains steady at 30 FPS.

Gods Eater Burst:-

Internal FPS during title screens plummets to below 30. Intro FMV Playback is also slowed down to 20 FPS at times.

Internal FPS during gameplay drops from 30 to 20 FPS.

Legends of Heroes Trails in the Sky:-

Title Screen FPS drops from 30 FPS to 0 FPS (!)

Game effectively hangs after, since you can't select any of the options.

If you're fast enough, you can skip the title screens and load your savegame, but then realise that the ingame internal FPS has dropped from 30 FPS to 17-20 FPS.

Weirdest thing is that the music seems to be playing smoothly as usual with the lower internal FPS.

Ys Seven:- Title screen slowdown from 30 to 20 FPS. Internal FPS during Gameplay drops from 30 to 17-20 FPS.

Black Rock Shooter:- Title screen and gameplay FPS drops from 30 to 20 FPS.

Hatsune Miku Project Diva 2nd:-

Severe internal FPS slowdown during the main menu featuring your character from 30 FPS to 13 FPS. Eventually drops to 0 VPS if left without input (or turboing), so the game effectively hangs after a short while.

If you somehow manage to get through and play a song, notice that the internal FPS during gameplay has also dropped from 30 to sub 20 FPS, rendering this highly timing sensitive game unplayable.

Tactics Ogre:- Fluctuating internal FPS in the title screens from 60 FPS to the 50s. Internal FPS at the world map drops from 60 FPS to 30 FPS. Internal FPS during gameplay drops from 60 FPS to 30 FPS.

Soul Calibur:- Probably one of the few native 60 FPS game I tested which managed to retain almost 60 FPS in all aspects with MT ON; FMVs, title screens and gameplay. No regressions here.

Persona 3 Portable:- Internal FPS slowdown during gameplay from 30 FPS to 20 FPS outside and inside Tartarus.

Untold Legends Brotherhood of the Blade:- Internal FPS during gameplay reduced from 60 FPS to 30 FPS.

MT ON:-

MT OFF:-

Kingdom Hearts BBS:- Another rarity. The internal FPS holds steady at 30 FPS during gameplay, title screens and the FMV cutscenes. Using the cheatcode to increase the internal FPS to 60 does not work anymore during gameplay however, and the FPS just holds steady at 30 FPS.

FF 1:- The Opening FMV does not play back smoothly, and looks like its running in slow motion. Internal FPS has lowered from 60 to the 30s.

Internal FPS during gameplay has also dropped from 60 to the upper 40s/lower 50s. One thing to note is that BGM playback is unaffected by the internal FPS drops.

FF 2:- FMV playback is unaffected. Internal FPS during gameplay drops from 60 to 30 FPS however.

FF 3:- FMV playback is unaffected and holds steady at 30 internal FPS. Internal FPS during gameplay holds steady at 30 FPS, as it was before.

Conclusion:-

It seems to me that a vast majority of the 60 FPS games, and a big number the 30 FPS games I tested have GE Timing issues again once Mutlthreaded is enabled. A minority of them do not however, but those are the exceptions.

The only 60 FPS game that does not have GE Timing issues again from my list is Soul Calibur.

Feel free to add any other games which haven't been covered by this list.

[unknownbrackets]

The screenshots really make this issue hard to read and not so useful. If you want to test so many games a chart/table would be way more helpful.

-[Unknown]

[solarmystic]

With https://github.com/hrydgard/ppsspp/pull/3119, a few games are now improved when MT is enabled.

Danganronpa is now perfectly normal as it was before, in both the cutscenes and gameplay

Monster Hunter Portable 3rd HD no longer hangs at the title screens and you can now head ingame. But the ingame FPS remains abysmal at sub 20 FPS.

Ditto for Monster Hunter Freedom Unite which now has improved FMV playback that is running smoothly, but horrendous internal FPS.

Legend of Heroes:- Trails in The Sky has also been fixed

Ys Seven has also been fixed

Black Rock Shooter has also been fixed

Tekken 5 DR and Tekken 6 also runs at 60 FPS internally once again with MT on.

Gundam Vs Gundam Next Plus is also back to 60 FPS internally.

@unknownbrackets

Fine then, I'll rework this into a chart or table. Just thought screenshots would be necessary for proof, lest anybody asks for it.

[unknownbrackets]

I don't think you're lying though, so it just makes for a lot of scrolling. I appreciate that you're trying to provide a ton of information, and I know all to well that it takes a lot of time to test so many games.

-[Unknown]

[solarmystic]

@unknownbrackets

Here are the results, tabulated in an easier to understand table without the screenshots getting in the way, updated with new ones obtained via further testing after your fix https://github.com/hrydgard/ppsspp/issues/3119 had been merged to master in 0.8.1-1222

[unknownbrackets]

Well, of those that still have problems I only have God Eater Burst... but I can reproduce it.

I've also noticed a random hang in Tales of Phantasia X (it seems like a process queue operation is being dropped, but I can't figure out why... the list is pending and a thread is waiting on it, but there's no process event so it hangs forever.)

Both of these are "fixed" (this is not a fix) by changing Core/ThreadEventQueue.h as so:

    void ScheduleEvent(Event ev) {
        {
            lock_guard guard(eventsLock_);
            events_.push_back(ev);
            eventsWait_.notify_one();
        }

        if (!threadEnabled_) {
            RunEventsUntil(0);
        } else if (EventType(ev) != EVENT_SYNC) {
            SyncThread();
        }
    }

This basically makes it process display lists synchronously, as before (but still on a separate thread.) That at least tells me the mechanics/scheduling is right, and either there's likely some threading interaction wrong or bugs when displaylists are executed asynchronously.

So far I also know Virtua Tennis has a similar issue, but with a diferent symptom: it's totally black afaiu.

Does the above not solve any of the issues you've experienced? If it doesn't, it means a totally different class of issue.

-[Unknown]

[solarmystic]

Actually, from the table that I made, you can clearly see that there are only a few games left that are unfixed by https://github.com/hrydgard/ppsspp/issues/3119 :-

Monster Hunter Freedom Unite Monster Hunter Portable 3rd HD Gods Eater Burst Project Diva 2nd

Anyway, I'll try out that alteration you suggested to Core/ThreadEventQueue.h and report back.

[unknownbrackets]

Right, I don't have any of the others on that list. There's definitely other games with issues still, though.

-[Unknown]

[unknownbrackets]

So, GEB is having horrible interrupt scheduling issues:

*** Trigger interrupt for 6786326356 ticks (at 6847936821 ticks, so in -61610465 ticks)
*** Advanced interrupt at 6848367604 (62040886 late)
*** Running interrupt type 0 at 6848367604

That's at least 10 frames (!) late, I'm not sure why, but I have an idea.

-[Unknown]

[solarmystic]

Heh, that seemed to have done the trick with the remaining games listed in my previous comment.

All of the games below are now rectified somewhat with that Core/ThreadEventQueue.h alteration you suggested:-

Monster Hunter Freedom Unite (back to 30 FPS everywhere) Monster Hunter Portable 3rd HD (ditto) Gods Eater Burst (ditto) Project Diva 2nd (ditto)

As an added bonus, it's safer to turbo through a majority of the games again with MT on, previously there was a very high probability that the game would crash if you turboed with MT on.

There's still a minor visual sideeffect (?) when MT is on in a number of games, like a very occasional black screen that flickers in certain games like the Monhun games and Gran Turismo, for instance.

When and if you decide to formally open a pull request to add those changes in, every game on that table would be fixed, at least in terms of the internal FPS, with MT on.

[unknownbrackets]

Hmm, don't have those games with the flicker. Anyway, the above isn't a fix, just a diagnosis. If we use that code, which was just for diagnosis, the GPU does not run at the same time as the CPU ever. In other words, it's exactly the same (and as slow) as single threaded, just more complicated.

The reason I asked was just to make sure they didn't have a totally different class of issue (that more complicated bit being broken.)

This fixes God Eater Burst, and it makes sense:

https://github.com/unknownbrackets/ppsspp/commit/639ab8306b7865acd084df0a51378f6c3cb1ac7e

Some interrupts are still running late, but not by such amazing degrees anymore.

-[Unknown]

[solarmystic]

There could definitely be other games that could be problematic and untested when it comes to MT in various other ways.

I'd still like to leave this issue report open (even after https://github.com/hrydgard/ppsspp/issues/3120 gets merged) , at least until Orphis buildbot starts working again, and we can get an idea of the far reaching effects of enabling Multithreaded in a bigger variety of games from other users who don't self compile PPSSPP and rely on said buildbot for builds.

[unknownbrackets]

Yeah, it's a shame it's still broken.

I just reproduced the random hang in God Eater Burst again, so it's still there. Have not found it yet, but it must be due to some hole in the listLock locking, I guess. I wish I had a consistent way to reproduce.

Standing right in front of Hibari I get ~1880% (except when it hangs), and ~1100% without. That's a ~63% improvement. With your weaker CPU and ATI card, what are you getting? I was hoping this would benefit you (and others with similar hardware.)

-[Unknown]

[solarmystic]

Not as much as you obviously.

With my Core 2 Duo T9550 and ATI Mobility 4670 card I'm getting:-

575% (345 VPS) with it on, and... the same with it off?

Yikes, let me check that again.

EDIT:- Yeah, I seem to be getting roughly the same Speed with or without MT in that game. Odd.

EDIT2:- The funny thing is that when a scenario like that happens in a game, enabling MT still caps CPU usage at 50% which means that the extra thread(?) is not being spawned, and the other core is not being used. Which is strange.

EDIT3:- Rofl, I know what happened, I used the build which had the "not-fix" implemented that you suggested for testing. It seems to give no benefits to MT for me.

[unknownbrackets]

Right, that's what I said - that diagnosis kills all the benefits. How is it without that?

-[Unknown]

[solarmystic]

Let me get back to you on that Unknown, I can't really tell until I manually merge your proposed "real fix" in the pull request you opened, since the game has a propensity to behave erratically with MT on in every single build before that fix. (as you already know)

[dbz400]

Regarding the overbright issue in FF Type-0 , it happned before and it is related to this

https://github.com/hrydgard/ppsspp/pull/1740

[solarmystic]

@unknownbrackets

I merged your proposed proper fix https://github.com/hrydgard/ppsspp/pull/3120 manually and tested Gods Eater Burst again, with and without MT, and now I could see the difference.

575% (345VPS) without MT 792% (472VPS) with MT

Not bad at all.

On the other hand, turboing in the Monhun games is now hazardous to health. Both games tested will just hang after a bit if you hold down the Unthrottle button.

[daniel229]

God of War Ghost of Sparta hang after this screen with multithreaded when Force 60 FPS or less disable since this commit https://github.com/hrydgard/ppsspp/commit/abc396cbe1e80fce48edad5633db7241ceb80455 . merged this https://github.com/hrydgard/ppsspp/pull/3120 still not help.

[unknownbrackets]

@daniel229 I added a couple more commits to #3120. The demo seems okay there, so maybe you hit the lock up that I'm having trouble reproducing.

-[Unknown]

[unknownbrackets]

@raven02 I wonder if the white in Type-0 is not just the wrong color (like the shadow)?

Unfortunately, the same hack as used in that pull will not work here. It will (as @solarmystic showed) be the same as turning the feature off, and it's already optional.

-[Unknown]

[daniel229]

@unknownbrackets merged the updated commits in https://github.com/hrydgard/ppsspp/issues/3120 fixed that issue.

[solarmystic]

@unknownbrackets

Yep, those two extra commits you added in https://github.com/hrydgard/ppsspp/issues/3120 also solved the crashes in both the Monhun games as well when unthrottling the framerate, nice work. That allowed me to see the gains when swicthing on MT, which are definitely present.

Seems like both cores are not being fully used though. Only getting 70-71% utlization on both, and I'm not GPU limited either in those situations. (running with GPUz open in the background for monitoring GPU Usage)

[unknownbrackets]

I'm still not sure why that is, although it has improved vastly for me (usually I have a pegged thread now.) There are some realities that could be causing it (synchronization/locks are not free, a lock-free model would be better but there are complexities...), but 70% is awful low...

-[Unknown]

[solarmystic]

Another interesting sideeffect of MT on a puny (relatively speaking) Core 2 CPU is that the emulator becomes much more "sensitive" to external events occuring in background applications.

e.g. opening up an instance of GPUz while turboing causes the screen to flicker black and performance to dip for a bit, before settling down, and heading back to the usual numbers.

Note to self:- Encoding a Video while enabling MT and running Tekken 6 on PPSSPP at the same time is a recipe for disaster on a Core 2.

ST (Single Threaded) is much more "resilient" somehow to these background changes, at least on my Core 2.

[unknownbrackets]

That's not really unexpected. The 2 threads running on separate cores depend on each other heavily. If you open another app, and it slows down only one of the 2 threads, it'll take the other down with it.

Single threaded doesn't have this problem.

-[Unknown]

[daniel229]

nVidia threaded optimization seems much effective in cpu usage.

ST about 25%~27% usage of 4cores

ST+nVidia threaded optimization about 39%~44% usage of 4cores

MT about 26%~30% usage of 4cores

MT+nVidia threaded optimization about 45%~52% usage of 4cores

[solarmystic]

Updated table with the latest results after fixes from https://github.com/hrydgard/ppsspp/pull/3120 are merged manually(will be known as 1230 when Henrik merges into master and if [Unknown] doesn't add anymore commits):-

Only 1 game left with Internal FPS trouble when MT is on; Project Diva 2nd.

[DonelBueno]

@solarmystic, I would like to test with this build too (1229), can you provide it to me?

I don't know how to compile the builds on my own. I installed Visual C++ 2010 Express, downloaded the ppsspp repository as a .zip file (I don't even know if this is the right way of getting the code for manual compilation) and tried to compile using the visual studio solution file inside the Windows folder, but the compilation failed due to a lot of errors Can you make a noob guide for that? Do I need the GitHub app installed?

[dbz400]

You need to download both ffmpeg and native zip then you should be able to compile it .

-Native https://github.com/hrydgard/native/archive/master.zip

-ffmpeg https://github.com/hrydgard/ppsspp-ffmpeg/archive/master.zip

[DonelBueno]

Thanks, raven02. I downloaded both submodules and put them into the master folder. The compilation went further, but still failed:

========== Build: 5 succeeded, 3 failed, 2 up-to-date, 0 skipped ==========

6>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

7> Creating library \ppsspp-master\Windows\Debug\PPSSPPHeadless.lib and object \ppsspp-master\Windows\Debug\PPSSPPHeadless.exp 7>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library 7>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

8> Creating library ..\PPSSPPDebug.lib and object ..\PPSSPPDebug.exp 8>MSVCRTD.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library 8>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

[solarmystic]

@DonelBueno

I've already made a noob compiling guide for Windows, C++ and git at the ppsspp.org forums here:-

http://forums.ppsspp.org/showthread.php?tid=5231

There's a reason it's stickied in the Development section of the forums.

Follow each and every step carefully.

I recommend that you start from scratch, since my guide assumes that you FOLLOW each and every step to the letter. Wipe out the repository you got, and start from the beginning again. Do NOT skip any step, seriously.

Do not MANUALLY download those submodules unless you know what you're doing. Using my guide, most of what you have to do should be automated.

@raven's advice is great if you're an advanced user, not if you're a beginner.

[unknownbrackets]

http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

You probably need to install updates. (steps to find this answer: 1. copy error message, 2. paste into Google, 3. select first result. That works super often.)

-[Unknown]

[solarmystic]

@DonelBueno

Anyway, if you still want that 1229 build for testing, here it is:-

(change the file extension to zip, unzip it to your ppsspp folder and run it)

[DonelBueno]

Thanks @unknownbrackets and @solarmystic.

@unknownbrackets, I know how to google, I just thought the error was related to a mistake I did while managing the ppsspp files.

I will follow your guide, @solarmystic, thanks again.

EDIT: downloading Visual C++ SP1 did the trick, the compilation went well this time.

I will use @solarmystic's guide anyway, as it automates all the process and is much more feature rich than what I did, lol.

[thedax]

Assassin's Creed Bloodlines doesn't take well to being multi-threaded, either. Its internal FPS drops to an abysmal 12 while in-game, though during FMVs it's fine at 30. The screen also periodically flickers black and back to normal, though it's only once like every 5-8 seconds.

The rest of the games I tried are either covered by @solarmystic or aren't affected at this time(by not affected I mean internal FPS, of course).

[i30817]

I hope you realize that there are lots of games hanging in master for some reason or other on linux amd64, even with the multithreaded option disabled.

I tried to do a bisect, but the repository is systematically broken in the intervening commits due to something wrong on GPU/GLES/FragmentShaderGenerator.cpp:31:

I only know that 1da49273b56d711ae7921e005ac21eb6fa5f3f65 is ok and that 7ba54b5dc09e39f04d3521e1df95753ac94aa461 (head) is bad, using trails in the sky to test if it goes into the main menu.

[hrydgard]

@i30817 , thanks for reporting, I have not noticed that. I'll see if I can repro on my mac tonight ... otherwise I guess I have to rescue my broken linux install or try to get it working in a VM again.

[unknownbrackets]

There shouldn't be anything wrong with FragmentShaderGenerator.cpp.

It's probably the filesystem stuff then. @i30817 what if you edit ppsspp.ini and set SeparateIOThread to False?

-[Unknown]

[i30817]

Yeah, that prevented things hanging.

The errors in FragmentShaderGenerator were things like this (just btw): ThreadEventQueue.h:94:38: error: ‘CORE_RUNNING’ was not declared in this scope make[2]: * [CMakeFiles/GPU.dir/GPU/GLES/FragmentShaderGenerator.cpp.o] Error 1 make[1]: * [CMakeFiles/GPU.dir/all] Error 2 make: *\ [all] Error 2

I think the policy in this cases when doing a bisect is to fix it locally, but you managed to pinpoint the cause anyway, so i'm not gonna bother.

[unknownbrackets]

I don't have a Linux box handy, I can try to look later. I probably did one thing wrong though...

What if you replace this (in ThreadEventQueue.h):

    void RunEventsUntil(u64 globalticks) {
        do {
            for (Event ev = GetNextEvent(); EventType(ev) != EVENT_INVALID; ev = GetNextEvent()) {
                switch (EventType(ev)) {
                case EVENT_FINISH:
                    // Stop waiting.
                    globalticks = 0;
                    break;

                case EVENT_SYNC:
                    break;

                default:
                    ProcessEvent(ev);
                }
            }

            // Quit the loop if the queue is drained and coreState has tripped, or threading is disabled.
            if (ShouldExitEventLoop() || !threadEnabled_) {
                return;
            }

            // coreState changes won't wake us, so recheck periodically.
            eventsWait_.wait_for(eventsWaitLock_, 1);
        } while (CoreTiming::GetTicks() < globalticks);
    }

    void SyncThread() {
        if (!threadEnabled_) {
            return;
        }

        // While processing the last event, HasEvents() will be false even while not done.
        // So we schedule a nothing event and wait for that to finish.
        ScheduleEvent(EVENT_SYNC);
        while (HasEvents() && coreState == CORE_RUNNING) {
            eventsDrain_.wait_for(eventsDrainLock_, 1);
        }
    }

With:

    void RunEventsUntil(u64 globalticks) {
        lock_guard guard(eventsWaitLock_);
        do {
            for (Event ev = GetNextEvent(); EventType(ev) != EVENT_INVALID; ev = GetNextEvent()) {
                switch (EventType(ev)) {
                case EVENT_FINISH:
                    // Stop waiting.
                    globalticks = 0;
                    break;

                case EVENT_SYNC:
                    break;

                default:
                    ProcessEvent(ev);
                }
            }

            // Quit the loop if the queue is drained and coreState has tripped, or threading is disabled.
            if (ShouldExitEventLoop() || !threadEnabled_) {
                return;
            }

            // coreState changes won't wake us, so recheck periodically.
            eventsWait_.wait_for(eventsWaitLock_, 1);
        } while (CoreTiming::GetTicks() < globalticks);
    }

    void SyncThread() {
        if (!threadEnabled_) {
            return;
        }

        lock_guard guard(eventsDrainLock_);
        // While processing the last event, HasEvents() will be false even while not done.
        // So we schedule a nothing event and wait for that to finish.
        ScheduleEvent(EVENT_SYNC);
        while (HasEvents() && coreState == CORE_RUNNING) {
            eventsDrain_.wait_for(eventsDrainLock_, 1);
        }
    }

-[Unknown]

[solarmystic]

Sorry to barge in.

Updated table with the fix from https://github.com/hrydgard/ppsspp/commit/7ba54b5dc09e39f04d3521e1df95753ac94aa461 merged into master by Henrik as of 0.8.1-1269

Project Diva 2nd remains the last remaining hold out in a list of 20+ odd games that behave appropriately when it comes down to their Internal FPS now with MT enabled.

Internal FPS during actual gameplay and FMVs are rock solid at 30 and 60 respectively, but the Character Screen FPS is still rather stubborn and is fluctuating between 20 - 30 FPS when MT is enabled.

[hrydgard]

@i30817 , I know it's too late but the fix for the fragmentgenerator issue is to #include Core/System.h somewhere early. On that note I think we have some include dependencies to clean up...

[solarmystic]

I'd also like to share a table of some rather rough VPS measurements I've taken in a rather limited (5) number of games to highlight performance changes across a wide range of revisions.

The games are Danganronpa, Crisis Core, Monster Hunter Freedom Unite, Monster Hunter Portable 3rd and Gran Turismo.

Note in particular the revisions after 1207, when I include MT ON numbers.

Testing locations

Danganronpa:- Loaded up a savefile in front of a doorway.

Crisis Core:- Loaded up at a save point at the Ground Floor of the Shinra Building

MHFU:- Right at the entrance to the village

MH3rdPHD:- Same as MHFU

GT:- At the starting line of the first quick race you have access to.

The point I wanted to highlight was that it seems like with every GPU/CPU sync fix, the Performance of every game in the list when MT is ON is demonstrably dropping with each subsequent revision, coming closer to MT OFF numbers. It seems like in the process of attaining perfect sync between the two threads, performance has been sacrificed for MT.

[hrydgard]

More sync = more overhead. However I think there will be plenty of room for tuning.

At least MT seems to provide a speedup almost all of the time.

[i30817]

@unknownbrackets seems to work to boot up LH:TitS even with the SeparateIOThread to 'True'

Jean of arc (eventually hangs) after this: 33:34:750 idle0 W[HLE]: ppsspp/Core/HLE/sceKernelThread.cpp:2615 sceKernelReleaseWaitThread(): Refusing to wake HLE-delayed thread, right thing to do?

But that probably has more to do with the numerous font errors in that game.

[unknownbrackets]

Yeah, @solarmystic basically that's why I'm not so worried about only one game at near-acceptable levels of FPS. I can probably fix that, but it will mean losing e.g. 5-10% performance across the board. There's already the option to turn it off...

Probably there's a more perfect way to solve it, though. Also, for me the performance drop of the recent change was actually pretty minor, it's unfortunate to see that it affects weaker CPUs more.

-[Unknown]

[solarmystic]

On a rather happier note, it seems like the buildbot is alive again.

I hope to see more reports coming in, especially with more users enabling the MT function on a lot more different games.

[VIRGINKLM]

I'm gonna do reports of all of my games, do you need Android reports too? The tests are with both [SeparateCPUThread = True] and [SeparateIOThread = True] at the same time right? 64bit or 32bit?(I guess it could differ?)

[solarmystic]

@VIRGINKLM

I'd advise you to keep [SeperateIOThread = False] for now, since a number of users seem to have issues with it. But otherwise, you're good to go. Android test results would be much appreciated.

[VIRGINKLM]

OK I'll start immediately.