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.
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>
After commit 51ca73cb, using a non-blocking socket (e.g. poll(..., timeout=0)) will still result in a blocking socket.
It appears the above commit inverted the behavior.
This merge request fixes the blocking flag: blocking will be set to false when the flag is 0x800.
* Fixed an issue where games would boot loop because of an incorrect HID state.
* Turns out the SamplingNumber of the atomic input storage doesn't match the SamplingNumber of the input state held by the atomic storage, instead it is exactly double the value in the input state.
* Added new Condition struct to the HID Shared memory and populate it with dummy data to fix the no-controller crash (already merged).
* The audio renderer has been mostly updated to rev15, allowing rev15 games to launch.
* Biquad filters now use floats.
* Several structures have been renamed to match the SDK names, making it easier to compare functionality. A few names are still missing and will be changed at a later date.
* The new commands from rev15 have been added to the CommandType enum, but they are still missing from the code itself.
* Due to changes in the SDK layout, the time estimation functions are either missing or very well hidden (or Ghidra search functionality is useless). We can't fully implement the new commands until the timing data has been located.
* A few minor tweaks to the code have been made to more accurately match the SDK.
A few more internal changes to the RangeList systems.
* No longer using a QuickAccess dictionary.
* The performance of the dictionary wasn't much faster than just doing binary searches.
* Using just binary searches allows us to take advantage of span and array returns as they're are faster than linked lists when iterating or copying the overlaps.
Small code optimizations.
Fixes a few leftover crashes.
* Slightly refactors RangeLists from the last Memory Changes MR, which fixes issue 61.
* Convert as many const size array iterators to span iterators as possible. When iterating over a const size array, every iteration created a Span, now only the first iteration does in most places.
* Now using object pooling for a few object types that were rapidly deleted and recreated.
* Converted a few flag checks to binary operations to save memory allocations.
* Refactors the RangeList and derivative classes used for handling lists of regions
* The Binary searches are now more performant, relying on edge searches instead of just returning the first matching hit and manually iterating until the edge is found
* Most look-ups now return a RangeItem, which acts as a linked list node now, instead where possible, moving away from Array copies. This should help with some specific lag spikes.
* Made IntrusiveRedBlackTreeNodes act like linked list nodes too to improve the lookup time of minimums, maximums and successors.
* Changed a few cases of HasFlag() into binary operations to save on memory allocations.
In general, [these changes] should increase frame time stability and lag spikes, but at the cost of some overhead to memory look-ups, the result being a very slightly better average fps from my testing (~1-2%).
LotP