hrydgard/ppsspp — pull request #435 by unknownbrackets (2013-01-18 08:45:03+00:00)
Title: Proper VPL rescheduling/waiting

Not too many games use VPLs (probably because of the confusing way you can't allocate 0x10 * 0x100 blocks of a 0x1000 VPL...), but for those that do, this should help.

I'd messed up some of my earlier tests on these and thought they were wiping memory - which they don't. But this makes waiting, cancel, delete, etc. all work correctly.

Unfortunately, it doesn't currently pass all tests (although it passes almost all, and is much better than before.) Some notes:

* My PSP will happily provide a 24 MB VPL (up to I think 28 or 29 MB.) I'm not sure the correct way to replicate this, and I assume it doesn't happen on PSP-1000's (of which I have none.) This makes threads/vpl/create fail currently.

* It seems like `sceKernelAllocateVpl()` might reschedule on success, but I'm not sure. I tested the games I have that import the vpl funcs, and the only one that cared was echochrome (demo)... and it made it crash. But the game isn't working anyway. I decided to err on not rescheduling, since JPCSP doesn't either.

* This also corrects an issue with semaphores waking by priority. My old code was just wrong. I'm planning to do some refactoring soon...

* BlockAllocator now maintains alignment even when `AllocAt()` is used, because I've seen the warning a couple times from ELF loading. It also returns consistent values on error now

By the way, memory alignment is definitely 256, but VPLs not aligned to 256 just waste that space. FPLs too, in fact, but not thread stacks (which is another issue I need to fix, they should be rounding up...)

I didn't update tests since they're not passing. At least threads/vpl/vpl does pass now.

-[Unknown]