* GPU: Fast path for adding one texture view to a group
Texture group handles must store a list of their overlapping views, so they can be properly notified when a write is detected, and a few other things relating to texture readback. This is generally created when the group is established, with each handle looping over all views to find its overlaps. This whole process was also done when only a single view was added (and no handles were changed), however...
Sonic Frontiers had a huge cubemap array with 7350 faces (175 cubemaps * 6 faces * 7 levels), so iterating over both handles and existing views added up very fast. Since we are only adding a single view, we only need to _add_ that view to the existing overlaps, rather than recalculate them all.
This greatly improves performance during loading screens and a few seconds into gameplay on the "open zone" sections of Sonic Frontiers. May improve loading times or stutters on some other games.
Note that the current texture cache rules will cause these views to fall out of the cache, as there are more than the hard cap, so the cost will be repaid when reloading the open zone.
I also added some code to properly remove overlaps when texture views are removed, since it seems that was missing.
This can be improved further by only iterating handles that overlap the view (filter by range), but so can a few places in TextureGroup, so better to do all at once. The full generation of overlaps could probably be improved in a similar way.
I recommend testing a few games to make sure nothing breaks.
* Address feedback
* Update sparsely mapped texture ranges without recreating
Important TODO in TexturePool. Smaller TODO: should I look into making textures with views also do this? It needs to be able to detect if the views can be instantly deleted without issue if they're now remapped.
* Actually do partial updates
* Signal group dirty after mappings changed
* Fix various issues (should work now)
* Further optimisation
Should load a lot less data (16x) when partial updating 3d textures.
* Improve stability
* Allow granular uploads on large textures, improve rules
* Actually avoid updating slices that aren't modified.
* Address some feedback, minor optimisation
* Small tweak
* Refactor DereferenceRequest
More specific initialization methods.
* Improve code for resetting handles
* Explain data loading a bit more
* Add some safety for setting null from different threads.
All texture sets come from the one thread, but null sets can come from multiple. Only decrement ref count if we succeeded the null set first.
* Address feedback 1
* Make a bit safer
* GPU: Scale counter results before addition
Counter results were being scaled on ReportCounter, which meant that the _total_ value of the counter was being scaled. Not only could this result in very large numbers and weird overflows if the game doesn't clear the counter, but it also caused the result to change drastically.
This PR changes scaling to be done when the value is added to the counter on the backend. This should evaluate the scale at the same time as before, on report counter, but avoiding the issue with scaling the total.
Fixes scaling in Warioware, at least in the demo, where it seems to compare old/new counters and broke down when scaling was enabled.
* Fix issues when result is partially uploaded.
Drivers tend to write the low half first, then the high half. Retry if the high half is FFFFFFFF.
* use Array.Empty() where instead of allocating new zero-length arrays
* structure for loops in a way that the JIT will elide array/Span bounds checking
* avoiding function calls in for loop condition tests
* avoid LINQ in a hot path
* conform with code style
* fix mistake in GetNextWaitingObject()
* fix GetNextWaitingObject() possibility of returning null if all list items have TimePoint == long.MaxValue
* make GetNextWaitingObject() behave FIFO behavior for multiple items with the same TimePoint
* Add flatpak release workflow
Co-authored-by: Mary <mary@mary.zone>
* infra: Update required SDK version to 7.0.200
---------
Co-authored-by: Mary <mary@mary.zone>
* Sockets: Properly convert error codes on MacOS
The error codes for MacOS are very different to how they are on windows or linux. An alternate mapping is used when the host operating system is MacOS.
This PR also defaults IsDhcpEnabled to true when interfaceProperties.DhcpServerAddresses is not available.
This change was already in `macos1`.
* Address feedback
* Add Post Processing Effects
* fix events and shader issues
* fix gtk upscale slider value
* fix bgra games
* don't swap swizzle if already swapped
* restore opengl texture state after effects run
* addressed review
* use single pipeline for smaa and fsr
* call finish on all pipelines
* addressed review
* attempt fix file case
* attempt fixing file case
* fix filter level tick frequency
* adjust filter slider margins
* replace fxaa shaders with original shader
* addressed review
This allows changing base application directory behavior at build time via FORCE_EXTERNAL_BASE_DIR.
This is intended to be used by nixpkgs and flathub builds.
I also added the missing patch for macOS that we have on macos1 to avoid invalidating code signature.
* Move Ryujinx folder to Application Support on macOS
* Create a symlink to preserve back compat
Co-authored-by: Ac_K <Acoustik666@gmail.com>
* Remove extra whitespace
* Don’t create a symlink
* Update Ryujinx.Common/Configuration/AppDataManager.cs
Co-authored-by: Ac_K <Acoustik666@gmail.com>
* Revert "Don’t create a symlink"
This reverts commit 31752fe8ab.
---------
Co-authored-by: Ac_K <Acoustik666@gmail.com>
* Use SIMD acceleration for audio upsampler filter kernel for a moderate speedup
* Address formatting. Implement AVX2 fast path for high quality resampling in ResamplerHelper
* now really, are we really getting the benefit of inlining 50+ line methods?
* adding unit tests for resampler + upsampler. The upsampler ones fail for some reason
* Fixing upsampler test. Apparently this algo only works at specific ratios
---------
Co-authored-by: Logan Stromberg <lostromb@microsoft.com>
I noticed that in Xenoblade 2, the game can end up spending a lot of time adding and removing tracking handles. One of the main causes of this is actually splitting existing handles, which does the following:
- Remove existing handle from list
- Update existing handle to end at split address, create new handle starting at split address
- Add updated handle (left) to list
- Add new handle (right) to list
This costs 1 deletion and 2 insertions. When there are more handles, this gets a lot more expensive, as insertions are done by copying all values to the right, and deletions by copying values to the left.
This PR simply allows it to look up the handle being split, and replace its entry with the new end address without insertion or deletion. This makes a split only cost one insertion and a binary search lookup (very cheap). This isn't all of the cost on Xenoblade 2, but it does significantly reduce it.
There might be something else to this - we could find a way to reduce the handle count for the game (merging on deletion? buffer deletion?), we could use a different structure for virtual regions, as the current one is optimal for buffer lookups which nearly always read, memory tracking has more of a balance between read/write. That's for a later date though, this was an easy improvment.
* Add blend microcode registers
* Add advanced blend support using host extension
* Remove debug message
* Use pre-generated table for blend functions
* XML docs
* Rename AdvancedBlendMode to AdvancedBlendOp for consistency
* Remove redundant code
* Fix some advanced blend related issues on Vulkan
* Formatting
* Clear CPU side data on GPU buffer clears
* Implement tracked fill operation that can signal other resource types except buffer
* Fix tests, add missing XML doc
* PR feedback
* ava: Refactor Updater.cs
Fix typos
Remove unused usings
Rename variables to follow naming scheme
* ava: Set file permissions when extracting update files
* gtk: Apply the same refactor to Updater.cs
* updater: Replace assert with if statement
* updater: Remove await usings again
* vulkan: Respect VK_KHR_portability_subset vertex stride alignment
We were hardcoding alignment to 4, but by specs it can be any values that
is a power of 2.
This also enable VK_KHR_portability_subset if present as per specs
requirements.
* address gdkchan's comment
* Make NeedsVertexBufferAlignment internal
This started as an attempt to remove vkGetPhysicalDeviceMemoryProperties
in FindSuitableMemoryTypeIndex (As this could have some overhead and
shouldn't change at runtime) and turned in a little bigger cleanup.
