-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Improve readyqueue perf, rapid fire, small improvements #651
Conversation
@unknownbrackets , should we expect Sol trigger work again in this commit ? :) |
No. I think I know why though. I think I managed to get Tales of Destiny 2 farther but it still crashes, so I'm not sure I did it right. -[Unknown] |
Agree that sceKernelThread is growing a bit too big, but it contains a lot of heavily interconnected functionality. So need to think carefully about which parts to break out and how their external interfaces should look. |
@@ -66,6 +67,8 @@ struct BaseEvent | |||
Event *eventPool = 0; | |||
Event *eventTsPool = 0; | |||
int allocatedTsEvents = 0; | |||
// Optimization to skip MoveEvents when possible. | |||
volatile u32 hasTsEvents = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't need to use volatile and atomic stores/loads as all the stuff touching this will always run on the main emulation thread. If it doesn't, we have other problems..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the whole point was to make ts (threadsafe) events faster. Those are ones scheduled from off thread, like savestates. Actually, savestates are the only consumer currently.
So before it kept calling MoveEvents()
, creating a mutex (which isn't slow but even so), and checking tsFirst
and allocatedTsEvents
. I wanted to cut that down to just a single check without a mutex and saving a function call. It's a small gain but when fast forwarding it adds up, and Advance is called not inoften.
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, sorry, it's me who's confused here. Never mind my comment.
Right... the only way really would be for sceKernelThread to expose more one way or another, unfortunately. -[Unknown] |
@@ -26,8 +26,12 @@ | |||
}; | |||
|
|||
int KeyboardDevice::UpdateState() { | |||
bool alternate = GetAsyncKeyState(VK_SHIFT) != 0; | |||
static int alternator = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, this should be unsigned.
-[Unknown]
Mostly to speed up debugging.
Pretty sure this is needed, but apparently it breaks Sol Trigger.
This saves ~1% during fast forward on a release build.
It showed up in a profile after all. Cut down more than 1%.
Just like .1% but was hoping Mr. Optimizer would do this for me.
Improve readyqueue perf, rapid fire, small improvements
So those atomic functions aren't working on many ARM devices. |
Are there alternatives? |
I think we could just use Otherwise, we could just revert the change, although it did improve perf and would be nice to have. -[Unknown] |
This does the following:
MoveEvents()
, since they're rare. I had trouble verifying this improved perf, but @KentuckyCompass's fps counter shows a reproducible improvement of maybe 2%.This significantly improves (mostly because of rapid fire, heh) the time it takes to get through the intro of Hexyz Force. Overall, in game fps improvement by ~5% on Windows release once past the intro.
sceKernelThread.cpp is kinda big, I'm wondering if breaking callbacks and maybe some things out into another file is realistic... I guess it's not hurting anyone, though...
-[Unknown]