Callbacks not implemented at all correctly #1082
Comments
|
Nicely investigated! When I implemented the first version of the callback system I really had no idea of any of this :-) I think whatever you do will look like a pile of hacks, and I'm sure that it looks like that in the real PSP OS too. Schedulers and synchronization are messy businesses and these strange Callback objects don't exactly make it easier... |
|
It gets even weirder. Semaphores run the callbacks before waiting (e.g. even if the sema is signaled.) In contrast (and I clearly didn't test this properly), lightweight mutexes don't even call callbacks unless they wait. Anyway, I've got Patapon 2 working now (not sure, probably other stuff is broken at the moment...) but there's definitely a lot more inconsistency with the *CB() funcs than I expected. -[Unknown] |
ghost
assigned
|
Wow. And as the scheduling is cooperative and not preemptive, games are able to, intentionally or not, grow dependent on every little scheduling quirk :( |
|
Causing problems in delay thread in Rockband, it seems: https://dl.dropboxusercontent.com/u/29021761/logs.7z Should be fixable, need to just change all the waits and rip out the defer thing. -[Unknown] |
|
Figured I'd clarify this to explain essentially how they at least seem to work. Basically, most (not all) ...CB() function can be imagined like this: int LockCB(SceUID uid)
{
int result;
while (true)
{
auto callbacks = GetCallbacks();
for (auto &callback: callbacks)
callback.call();
result = TryLock(uid);
if (result != NEEDS_WAIT)
return result;
++uid->numWaiting;
int result = WaitChangeOrCallbacks(uid);
--uid->numWaiting;
}
}In that, for example if I trigger two callbacks, then LockCB, and inside the first callback trigger a third callback, and call LockCB again from within callback 1, only callback 3 will run (2 is still pending.) Once callback 1 returns, callback 2 will run. Annoying. Notably, LwMutexes are an exception to this rule. So far everything else seems to fit this pattern. -[Unknown] |
|
I guess we are closer now, thanks to all your work on this? |
|
Yes, but it's still got some problems, I have changes for it but they break other things, need to get back to it... -[Unknown] |
|
@hrydgard what if we made the CPU re-entrant? Here's what I'm thinking:
I actually think this would work, but maybe I'm missing something. It's not like the jit can't run inside a syscall - it doesn't really have any troublesome state anyway. This way mipscalls and callbacks would be a lot easier. For example sceFont's callbacks would probably be fairly easy to write, callbacks would be easy to reschedule properly without lots of complexity, etc. The only three risks I can think of are recursion (mipscalls inside of mipscalls), threading, and savestates. I don't think recursion is a practical worry, but it would be possible for a game to enter a callback, reschedule, enter a new callback, etc. on a bunch of threads, and we'd descend deep into the stack. I don't think this would ever happen, and anyway it would eat stack space on the PSP if this happened too (although distributed on separate threads... I think we have more stack space than even all threads combined do in most any PSP game.) I also think multithreading works everywhere, although it currently has glitches (but only from async gpu calls.) For savestates, we currently (incorrectly) disallow rescheduling within callbacks. So I don't think any game ever spends very long inside a mipscall/callback. Currently you can savestate while stepping inside a callback, and this would be the main loss. -[Unknown] |
|
I'm fine with losing the ability to savestate within a mipscall, as long as we can savestate every frame I'm mostly happy enough although it's sometimes helpful for debugging to do it while stepping around. Anyway, I think that we really, really want to have an execution mode that's 100% deterministic in the long run - especially if we want to make the TAS crowd happy with input-state movie recording/playback and so on - which is the single core mode. Running the GPU and CPU on separate threads will always introduce some non-determinism, unless we synch until the point where there's a performance loss rather than a gain from multithreading. So unless we can find a way to allow cpu reentrance (which I'm not really against) while still timeslicing enough to make single-core emulation possible, I don't see this working out unfortunately. |
|
The only time that cpu and gpu are running concurrently is after a sceGeListEnQueue(), sceGeListUpdateStallAddr(), etc. They all call: ScheduleEvent(GPU_EVENT_PROCESS_QUEUE);Which tells the thread to start doing stuff. If the thread is not enabled, it then immediately runs the item from the queue: if (!threadEnabled_) {
RunEventsUntil(0);
}We could, instead use SyncThread here to wait for the other thread to complete: if (!threadEnabled_) {
RunEventsUntil(0);
} else if (threadOnlyPartiallyEnabledOrSomething) {
SyncThread();
}Which uses a condition variable to wait. This would have the same behavior as current, and I'm not sure it would really have some kind of significant performance loss. -[Unknown] |
|
I wonder if this is why I can't get sleep mode to work properly. I'm sending the correct power event flags to the games (pardon the extremely messy code, I'll be making it much nicer if/when it's ever ready), here at thedax@63195ba, but most of them ignore it, and I've found only two that wake up correctly (Diva 2nd and Outrun 2006). FF Type-0 just hangs forever once it's suspended, with the bad mojo warning. I can't get the power sample at https://github.com/hrydgard/pspautotests/blob/master/demos/power.pbp to even recognize that the power switch was pressed.. |
|
They will typically have a thread sleeping using sceKernelThreadSleepCB(). Theoretically, sending a callback notification should wake up said thread. But yeah, waiting during callbacks Just Doesn't Work right now. -[Unknown] |
|
Thanks for the reply. Hopefully sleep mode will be able to work once this is fixed at some point. |
|
@thedax how do the power callbacks work now? Although, I think it may be a separate issue. -[Unknown] |
|
@unknownbrackets: No clue. I'll check tomorrow or Monday. I think I still have my power branch.. |
|
They work a little better now. I can get Type-0 to stop its music, but the game still runs all of the 3D/game input stuff, so it's still partially ignoring it. I'll open up a separate issue later, so we can try and figure out how it works. |
|
f > fs/2 & fs - f.....analiasink. Here, on the example of it: { } |
|
Generalizations, it won't turn out all the same. . |
|
Does anyone know what @QWEmct is talking about? If not I'd like to post this image to describe my reaction to his last few posts |
|
About that it is necessary to divide into groups. Depending on video accelerators and processor. |
|
@QWEmct Ok, and what does that have to do with "Callbacks not implemented at all correctly" ? |
|
At this message a straight line influence to a question. From this point, it is necessary to begin construction. |
|
I can not make sense of what you are writing, please, please, please use actual English sentences. |
|
unknownbrackets, Dumping in an entrance to a way of a profile ,what to kill load effects in a menu mode. The "transition to the menu" button to return problem, in a starting position: ..../ To dump activity of loading of an operating system for the program. |
|
Your comments are not related to callbacks. I recommend you explain your problems here: Ask someone else to help you get these things explained. The problem is, none of us can understand you. Sorry. -[Unknown] |
|
You gave to me the reference to a dead forum. |
|
@QWEmct you can't expect people to reply to you in a matter of hours, especially if you're not posting to an international audience. But what else can we do? We can't understand you and you refuse to find someone to translate, so all we can do is link you to a place where you might find someone to help. |
|
I want to help you. And then to buy the working appendix for the device. |
|
@QWEmct We cannot understand you. Let me show how little we understand by giving you the definition to "appendix":
|
|
Wow... really so everything is bad. ...) |
Patapon 2 is currently broken because of this. Any game that shows "UNTESTED - waiting within callback - probably bad mojo?" is probably affected.
Currently, we have "callbacks" which are PSP kernel objects with uids (not to be confused with mipscalls.) In PPSSPP, callbacks are pretty special:
It turns out, this isn't exactly how they operate. In fact:
sceKernelWaitSemaCB()'s.sceKernelWaitSemaCB()itself.This is pretty different. I can kind of hack it by making it so waiting within a wait will work, but it will still cause hangs if things are deleted or in some cases.
I'm not sure exactly how to implement this correctly. I suppose on the hardware, it actually stops waiting when entering a callback, calls the callback, and then once it returns calls the wait function again.
I suppose this will require c++ callbacks per wait type, and checking them when enters/exits a callback to more correctly unwait/rewait. And timeouts will have to be specially handled too...
Edit: also, I suspect that we don't currently wake a thread if the callback occurs after it starts waiting, not sure.
-[Unknown]
The text was updated successfully, but these errors were encountered: