Use a separate thread for reading/writing #3126
Conversation
Also separate the logic for exiting the loop based on coreState. IO and audio won't necessarily be tied to the frame.
Not actually running anything on it yet.
This should improve stutter. Also verified via a timer to improve performance (although, not very much, ~0.07 seconds during an entire game load.)
|
Great stuff. |
Use a separate thread for reading/writing
|
Well done mate, this commit actually made Dead or Alive Paradise boot up in PPSSPP for the first time ever. It actually NEEDS SeparateIOThread = True otherwise it won't boot up. If I change it back to False, the game refuses to boot up again. The opening FMV plays properly. BGM and other audio works properly It hangs after choosing an option in the main menu however. Further details in the ppsspp.org forum thread:- http://forums.ppsspp.org/showthread.php?tid=1835&pid=41121#pid41121 Logfile until it hangs:- |
|
That implies someone depended on memory not being filled immediately. Unfortunately, even with SeparateIOThread enabled, it doesn't do that reliably. Properly doing it on an HLE thread is probably needed. I had a feeling some game would depend on it. It might improve things to set this to 0 in sceIo.cpp: const int IO_THREAD_MIN_DATA_SIZE = 256;But it still will be a race condition without the HLE threads. -[Unknown] |
|
Is it possible put the controls on a separate thread? |
|
On Windows, keyboard is already on a separate thread (the Windows GUI thread.) Controllers are currently not event based, and polled 60 times per second. But, in a recent profile I did see a XInput func, not sure why. I'm not sure of the situation exactly on Android, but it's event based. So in other words, probably not worth it. Audio/video/music processing are all that's really left, well and I guess some of savedata could be as well. There are also parts of texture decoding that could take better advantage of >= 3 core cpus. But there's also a bunch of ways to improve them with SSE/NEON. -[Unknown] |
This is enabled by default currently, since it should be pretty safe.
When HLE read/write functions are called, they're now read on a thread while the CPU/GPU continue doing their thing. Primarily goal here is to reduce stutter a bit during larger disk reads especially (since they were previously synchronous.)
The IO is not actually overlapped/async (which it's possible the PSP does support.) It uses the same blocking functions and a queue, but runs in parallel to the CPU.
Timing showed that this was also a net performance win, although a very small one (but that means the overhead of waiting and checking the thread was made up for.)
Unlike the GPU change, this change is entirely driven by the CPU. The only observable difference is that now, after calling
sceIoReadAsync(), the buffer will not already be filled (which is how it works on an actual PSP.)Of course, there's more that can be done. IO seems to happen on the PSP using actual thread scheduling and priorities, which are still ignored.
-[Unknown]