* Gommon to 2.8.0.1
* Microsoft.NET.Test.Sdk to 18.0.0
* Newtonsoft.Json to 13.0.4 (reduces trim warnings by 56)
* Ryujinx.LibHac to 0.21.0-alpha.126
* System group to 9.0.10
* UnicornEngine.Unicorn to 2.1.4-a40db6c
General memory improvements to decrease GC pressure and frequency.
Pool big arrays and objects that are created and deleted often.
Skip data copies when they aren't needed.
Inline flag checks to skip unneeded allocations.
From my testing the performance is about the same, but the GC frequency is much lower and collection is faster causing less and smaller spikes.
This lets games such as The Legend of Zelda: Tears of the Kingdom (v1.4.2) and other SDK 20+ games successfully circumvent a crash when calling an applet.
Example: No controller connected on boot -> calls Controller Applet -> no stub = crash.
ObjectPool now uses ConcurrentBag instead if ConcurrentStack, as it has a smaller memory footprint.
Fix compiler warnings related to Audio Command Pools.
Switch gpu command initialization to use pointers, that way skipping the allocation of the command which is unnecessary.
Skip byte array allocation in Ioctl2/3 if it isn't needed (if the source data is all continuous we don't need to copy it to make it continuous).
Revert and reimplement Float BiquadFilterEffect support, fixes infinite load issues in a few games like Splatoon 3.
Fix incorrect string check with the new thread naming system.
Implement object pooling for all Audio Commands and a few other audio related objects and use a growing error list for updating wave buffers instead of always allocating space for 8 errors.
Currently, application list will not show until ApplicationLibrary_LdnGameDataReceived calls ViewModel.RefreshView();, forcing a refresh. This makes application list load slowly when RyuLDN is enabled.
Newer applications have a folder for ounce in the Control nca. This fixes Ryujinx trying to open a folder as a file, causing another exception, when trying to find the icon fallback.
When users enable GDB stub, we assume they intend to use it (it slows down the game a lot). If the server cannot start, we abort to save users' time troubleshooting why their GDB client can not connect.
- Move the message handler into its debugger class part,
- Move all message types into one file and collapse 3 of the ones with no data into a generic, stateless message with a single property being its type,
- Add an Fpscr helper property on IExecutionContext along with a comment about what Fpscr is (similar to the other registers in there)
- Moved the Rcmd helpers (such as GetRegisters, GetMinidump, etc) into a dedicated Debugger class part,
- Fixed the double-collection (ToArray being called twice) in GetThreadUids & GetThread in KProcess
- convert GdbRegisters utilities into extensions on IExecutionContext
- add a Write/Read Register helper on Debugger that handles 32/64 bit instead of doing that for every usage of register reading/writing
Using resolution mods, heaps past 8 GiB work in some games (like LoZ: TotK) and not in others (like SMP Jamboree). Setting the heap to a hard limit of 8 GiB on the 10 & 12 GiB DRAM options seems to be the safe bet right now until a better solution is found.
When GDB stub is enabled, CheckSynchronization is called too frequently because it skips _nativeContext.SetCounter(MinCountForCheck) (called in CheckInterrupt()), causing CheckSynchronization to be constantly called in JIT. This could cause performance issue.
It also skips the call to the KProcess.InterruptHandler, which causes some games to deadlock when GDB stub is enabled.
I'm not sure if this change will cause any side effects, but it seems GDB stub is still working correctly after this change.
This change will not affect regular users.
The heap was limited to 6 GiB no matter the memory setting, causing memory configurations above 8 GiB to not actually affect the heap size.
Now when the memory config is set to [10 or] 12 GiB the heap also allocates 12 GiB.
The SetHeapSize SysCall will now allow heap sizes up to 12 GiB (technically slightly less).
Co-authored-by: KeatonTheBot <keaton@ryujinx.app>
Currently, some logs can be missing when a fatal error occurs (especially GuestBrokeExecutionException).
This MR attempts to flush logs to console and file before process exit.
