- Services now use their actual names when creating processes instead of the generic "Service".
- Services now use their names encapsulated in curly brackets for threads, e.g. {HID}, instead of the default "HLE.OsThread", making it easier to see what is actually happening behind the scenes. Client threads should use <> and host threads should use {}.
- Fixed a bug where initiating services would create extra unneeded servers.
This is part 1 of a series of service and Horizon changes i'm working on. More will follow at a later date.
if a buffer is inherited, ignore it and remove it from the list.
fixes a crash when a buffer is inherited during a sync and the containing ranges have been modified to not fit in the old buffer.
Fixes a few crashes:
- fixes a crash related to waking threads (priorities were wrong).
- fixes a crash from reusing the SetRenderTargets texture array (left-over data causing issues).
- fixes a mistake and an oversight in the buffer system.
- buffers were getting updated wrong causing bad data to be stored or some times cut.
- modified ranges would extend past their old buffers, crashing on syncs. Old buffers are now skipped as the new buffers already sync instead.
Introduces pooling in a few more places to increase memory efficiency.
simplified RangeList item logic.
- removed RangeItem by making all the range objects use the I(NonOverlapping)Range interface.
- BufferCache class no longer locks its RangeList, as the list is only ever accessed synchronously.
Small change to how keyboard snapshots are stored.
Increase ThreadedRenderer SpanPool size to fit slightly more data (4MB -> 8MB).
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.
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