- Mar 30, 2019
-
-
bunnei authored
video_core/{gl_rasterizer, gpu_thread}: Remove unused class variables where applicable
-
bunnei authored
kernel/scheduler: Minor tidying up
-
bunnei authored
service/fatal: Name FatalInfo structure members
-
Lioncash authored
Since C++17, we no longer need to explicitly specify the type of the mutex within the lock_guard. The type system can now deduce these with deduction guides.
-
Lioncash authored
-
Lioncash authored
Resolves a -Wextra-semi warning.
-
Lioncash authored
Based off RE, most of these structure members are register values, which makes, sense given this service is used to convey fatal errors. One member indicates the program entry point address, one is a set of bit flags used to determine which registers to print, and one member indicates the architecture type. The only member that still isn't determined is the final member within the data structure.
-
- Mar 29, 2019
- Mar 28, 2019
- Mar 27, 2019
-
-
Fernando Sahmkow authored
-
Fernando Sahmkow authored
-
Fernando Sahmkow authored
-
Fernando Sahmkow authored
-
Fernando Sahmkow authored
-
Fernando Sahmkow authored
-
Lioncash authored
The pusher instance is only ever used in the constructor of the ThreadManager for creating the thread that the ThreadManager instance contains. Aside from that, the member is unused, so it can be removed.
-
Lioncash authored
This member variable is no longer being used, so it can be removed, removing a dependency on EmuWindow from the rasterizer's interface"
-
Lioncash authored
Ensures that the signatures will always match with the base class. Also silences a few compilation warnings.
-
Lioncash authored
smaphore -> semaphore
-
- Mar 26, 2019
-
-
bunnei authored
kernel/process: Remove unused AddressMapping struct
-
bunnei authored
core/core_timing: Make callback parameters consistent
-
bunnei authored
kernel/kernel: Remove unnecessary forward declaration
-
bunnei authored
core/cheat_engine: Make MemoryReadImpl and MemoryWriteImpl internally linked
-
- Mar 24, 2019
-
-
Lioncash authored
These don't need to be visible outside of the translation unit, so they can be enclosed within an anonymous namespace.
-
Lioncash authored
In some cases, our callbacks were using s64 as a parameter, and in other cases, they were using an int, which is inconsistent. To make all callbacks consistent, we can just use an s64 as the type for late cycles, given it gets rid of the need to cast internally. While we're at it, also resolve some signed/unsigned conversions that were occurring related to the callback registration.
-
Lioncash authored
This is no longer necessary, as ResultVal isn't used anywhere in the header.
-
Lioncash authored
Another leftover from citra that's now no longer necessary.
-
Lioncash authored
One behavior that we weren't handling properly in our heap allocation process was the ability for the heap to be shrunk down in size if a larger size was previously requested. This adds the basic behavior to do so and also gets rid of HeapFree, as it's no longer necessary now that we have allocations and deallocations going through the same API function. While we're at it, fully document the behavior that this function performs.
-
Lioncash authored
Makes it more obvious that this function is intending to stand in for the actual supervisor call itself, and not acting as a general heap allocation function. Also the following change will merge the freeing behavior of HeapFree into this function, so leaving it as HeapAllocate would be misleading.
-
Lioncash authored
In cases where HeapAllocate is called with the same size of the current heap, we can simply do nothing and return successfully. This avoids doing work where we otherwise don't have to. This is also what the kernel itself does in this scenario.
-
Lioncash authored
Over time these have fallen out of use due to refactoring, so these can be removed.
-
Lioncash authored
This isn't required anymore, as all the kernel ever queries is the size of the current heap, not the total usage of it.
-
Lioncash authored
Another holdover from citra that can be tossed out is the notion of the heap needing to be allocated in different addresses. On the switch, the base address of the heap will always be managed by the memory allocator in the kernel, so this doesn't need to be specified in the function's interface itself. The heap on the switch is always allocated with read/write permissions, so we don't need to add specifying the memory permissions as part of the heap allocation itself either. This also corrects the error code returned from within the function. If the size of the heap is larger than the entire heap region, then the kernel will report an out of memory condition.
-
bunnei authored
core/hle/kernel: Split transfer memory handling out into its own class
-
- Mar 23, 2019