Applications can request the kernel to allocate a piece of the linear heap for them when creating a shared memory object.
Shared memory areas are now properly mapped into the target processes when calling svcMapMemoryBlock.
Removed the APT Shared Font hack as it is no longer needed.
This removes explicit checks sprinkled all over the codebase to instead
just have the SW rasterizer expose an implementation with no-ops for
most operations.
May fix additional texture caching issues. (Though mostly in homebrew, I
haven't seen any commercial software use this to flush anything but
command lists.)
* IncomingDisplayTransfer: Triggered just before a display transfer is performed.
* GSPCommandProcessed: Triggered right after a GSP command is processed.
* BufferSwapped: Triggered when the frames flip
This commit fixes several kernel object leaks. The most severe of them
was threads not being removed from the private handle table used for
CoreTiming events. This resulted in Threads never being released, which
in turn held references to Process, causing CodeSets to never be freed
when loading other applications.
This is exposed in the GUI as a new "CiTrace Recording" widget.
Playback is implemented by a standalone 3DS homebrew application (which only runs reliably within Citra currently; on an actual 3DS it will often crash still).
memory.cpp/h contains definitions related to acessing memory and
configuring the address space
mem_map.cpp/h contains higher-level definitions related to configuring
the address space accoording to the kernel and allocating memory.
Involves making asserts use printf instead of the log functions (log functions are asynchronous and, as such, the log won't be printed in time)
As such, the log type argument was removed (printf obviously can't use it, and it's made obsolete by the file and line printing)
Also removed some GEKKO cruft.
Hardware testing determined that the GSP processes shared memory
framebuffer update info even when no memory transfer or filling GX
commands are used. They are now updated on every interrupt, which isn't
confirmed correct but matches hardware behaviour more closely.
This also reverts the hack introduced in #404. It made a few games
behave better, but I believe it's incorrect and also breaks other games.
PDC0 and PDC1 are both VBlank interrupts. PDC0 was being treated as a
HBlank interrupt and fired many more times than it should. They now both
fire together at 60 Hz. This puzzlingly *improves* apparent framerate on
many applications.
A few other interrupts were being fired inside the GSP command
processing instead of on the actual GPU register writes, so they were
moved there, which should cover direct writes tho those registers not
going through the GX command queue.
MerryMage