anonymous/yuzu - yuzu is the world's most popular, open-source, Nintendo Switch emulator — started by the creators of Citra. It is written in C++ with portability in mind,

	Commit message (Collapse)	Author	Age	Files	Lines
*	hle: kernel: Migrate to KMemoryBlock, KMemoryBlockManager, and others.	bunnei	2021-02-19	1	-3/+3
\|
*	core: hle: kernel: object: Implement Finalize() virtual method.	bunnei	2021-01-29	1	-0/+2
\|
*	kernel: transfer_memory: Refactor for new VMM.	bunnei	2020-04-17	1	-37/+10
\|
*	core: memory: Move to Core::Memory namespace.	bunnei	2020-04-17	1	-4/+4
\| \| \| \|	- helpful to disambiguate Kernel::Memory namespace.
*	kernel: transfer_memory: Properly reserve and reset memory region.	bunnei	2020-02-06	1	-2/+17
\|
*	kernel: Remove unnecessary includes	Lioncash	2019-12-08	1	-1/+0
\| \| \| \| \| \|	Over the course of the changes to the kernel code, a few includes are no longer necessary, particularly with the change over to std::shared_ptr from Boost's intrusive_ptr.
*	kernel: Replace usage of boost::intrusive_ptr with std::shared_ptr for kernel objects. (#3154)	bunnei	2019-11-25	1	-5/+5
\| \| \| \| \| \|	* kernel: Replace usage of boost::intrusive_ptr with std::shared_ptr for kernel objects. - See https://github.com/citra-emu/citra/pull/4710 for details.
*	VM_Manager: Align allocated memory to 256bytes	Fernando Sahmkow	2019-07-19	1	-1/+2
\| \| \| \| \| \|	This commit ensures that all backing memory allocated for the Guest CPU is aligned to 256 bytes. This due to how gpu memory works and the heavy constraints it has in the alignment of physical memory.
*	kernel/transfer_memory: Add accessors to data and sizes	Lioncash	2019-04-03	1	-4/+16
\| \| \| \|	Also amend erroneous use of size_t. We should be using u64 here.
*	core/hle/kernel: Split transfer memory handling out into its own class	Lioncash	2019-03-13	1	-0/+91
	Within the kernel, shared memory and transfer memory facilities exist as completely different kernel objects. They also have different validity checking as well. Therefore, we shouldn't be treating the two as the same kind of memory. They also differ in terms of their behavioral aspect as well. Shared memory is intended for sharing memory between processes, while transfer memory is intended to be for transferring memory to other processes. This breaks out the handling for transfer memory into its own class and treats it as its own kernel object. This is also important when we consider resource limits as well. Particularly because transfer memory is limited by the resource limit value set for it. While we currently don't handle resource limit testing against objects yet (but we do allow setting them), this will make implementing that behavior much easier in the future, as we don't need to distinguish between shared memory and transfer memory allocations in the same place.