It seems that certain games (Link's Awakening, Xenoblade DE) had their fences reached already when posting framebuffers, so the signal that a frame was ready would go out _before_ the frame was enqueued, and the render loop would fail to dequeue anything and "skip" a frame.
This was resulting in their performance lowering dramatically after some loading transitions, as a frame signal would be consumed and presentation would be one frame behind.
It's possible this might have eventually caused deadlocks in these games or others, if it happened twice.
Some games (GameMaker Studio) build texture atlases out of sprites during initialization, using the 2D copy method. These copies are done from textures loaded into memory, not rendered, so they are not scaled to begin with.
I had set srcTexture in these copies to force scaling, but really it only needs to scale if the texture already exists and was scaled by rendering or something else. I just set that to false, so it doesn't change if the texture is scaled or not. This will also avoid the destination being scaled if the source wasn't. The copy can handle mismatching scales just fine.
This prevents scaling artifacts in GMS games, and maybe others (not Super Mario Maker 2, that has another issue).
* spl: Implement IGeneralInterface GetConfig
This PR implement the GetConfig call of the spl service. This is currently needed for some homebrews which currently needs Ignore Missing Service to boot. Now it's fixed.
Implementation was done using Atmosphère code and REing too.
* Addresses gdkchan feedback
* Optimize `TryAllocateRegWithtoutSpill` a bit
* Add a fast path for when all registers are live.
* Do not query `GetOverlapPosition` if the register is already in use
(i.e: free position is 0).
* Do not allocate child split list if not parent
* Turn `LiveRange` into a reference struct
`LiveRange` is now a reference wrapping struct like `Operand` and
`Operation`.
It has also been changed into a singly linked-list. In micro-benchmarks
traversing the linked-list was faster than binary search on `List<T>`.
Even for quite large input sizes (e.g: 1,000,000), surprisingly.
Could be because the code gen for traversing the linked-list is much
much cleaner and there is no virtual dispatch happening when checking if
intervals overlaps.
* Turn `LiveInterval` into an iterator
The LSRA allocates in forward order and never inspect previous
`LiveInterval` once they are expired. Something similar can be done for
the `LiveRange`s within the `LiveInterval`s themselves.
The `LiveInterval` is turned into a iterator which expires `LiveRange`
within it. The iterator is moved forward along with interval walking
code, i.e: AllocateInterval(context, interval, cIndex).
* Remove `LinearScanAllocator.Sources`
Local methods are less susceptible to do allocations than lambdas.
* Optimize `GetOverlapPosition(interval)` a bit
Time complexity should be in O(n+m) instead of O(nm) now.
* Optimize `NumberLocals` a bit
Use the same idea as in `HybridAllocator` to store the visited state
in the MSB of the Operand's value instead of using a `HashSet<T>`.
* Optimize `InsertSplitCopies` a bit
Avoid allocating a redundant `CopyResolver`.
* Optimize `InsertSplitCopiesAtEdges` a bit
Avoid redundant allocations of `CopyResolver`.
* Use stack allocation for `freePositions`
Avoid redundant computations.
* Add `UseList`
Replace `SortedIntegerList` with an even more specialized data
structure. It allocates memory on the arena allocators and does not
require copying use positions when splitting it.
* Turn `LiveInterval` into a reference struct
`LiveInterval` is now a reference wrapping struct like `Operand` and
`Operation`.
The rationale behind turning this in a reference wrapping struct is
because a `LiveInterval` is associated with each local variable, and
these intervals may themselves be split further. I've seen translations
having up to 8000 local variables.
To make the `LiveInterval` unmanaged, a new data structure called
`LiveIntervalList` was added to store child splits. This differs from
`SortedList<,>` because it can contain intervals with the same start
position.
Really wished we got some more of C++ template in C#. :^(
* Optimize `GetChildSplit` a bit
No need to inspect the remaining ranges if we've reached a range which
starts after position, since the split list is ordered.
* Optimize `CopyResolver` a bit
Lazily allocate the fill, spill and parallel copy structures since most
of the time only one of them is needed.
* Optimize `BitMap.Enumerator` a bit
Marking `MoveNext` as `AggressiveInlining` allows RyuJIT to promote the
`Enumerator` struct into registers completely, reducing load/store code
a lot since it does not have to store the struct on the stack for ABI
purposes.
* Use stack allocation for `use/blockedPositions`
* Optimize `AllocateWithSpill` a bit
* Address feedback
* Make `LiveInterval.AddRange(,)` more conservative
Produces no diff against master, but just for good measure.
Fixes a regression from #2663 where buffer flush would not happen after a resize. Specifically caused the world map in Yoshi's Crafted World to flash.
I have other planned changes to this class so this might change soon, but this regression could affect a lot so it couldn't wait.
* Add `Operand.Label` support to `Assembler`
This adds label support to `Assembler` and enables branch tightening
when compiling with relocatables. Jump management and patching has been
moved to the `Assembler`.
* Move instruction table to `Assembler.Table`
* Set PTC internal version
* Rename `Assembler.Table` to `AssemblerTable`
This fixes a potential regression with the new range list changes, where the cost for creating new ones would be rather large due to creating a 1024 size array. Also reduces cost for range list inheritance by using the first existing range list as a base, rather than creating a new one then adding both lists to it.
The growth size for the RangeList is now identical to its initial size. Every 32 elements was probably a little too common - now it is 1024 for most things and 8 for the buffer modified range list.
The Unmapped and SyncMethod methods have been changed to ensure that they behave properly if the range list is set null. Cleaned up a few calls to use the null-conditional operator.
* Replace CacheResourceWrite with more general "precise" write
The goal of CacheResourceWrite was to notify GPU resources when they were modified directly, by looking up the modified address/size in a structure and calling a method on each resource. The downside of this is that each resource cache has to be queried individually, they all have to implement their own way to do this, and it can only signal to resources using the same PhysicalMemory instance.
This PR adds the ability to signal a write as "precise" on the tracking, which signals a special handler (if present) which can be used to avoid unnecessary flush actions, or maybe even more. For buffers, precise writes specifically do not flush, and instead punch a hole in the modified range list to indicate that the data on GPU has been replaced.
The downside is that precise actions must ignore the page protection bits and always signal - as they need to notify the target resource to ignore the sequence number optimization.
I had to reintroduce the sequence number increment after I2M, as removing it was causing issues in rabbids kingdom battle. However - all resources modified by I2M are notified directly to lower their sequence number, so the problem is likely that another unrelated resource is not being properly updated. Thankfully, doing this does not affect performance in the games I tested.
This should fix regressions from #2624. Test any games that were broken by that. (RF4, rabbids kingdom battle)
I've also added a sequence number increment to ThreedClass.IncrementSyncpoint, as it seems to fix buffer corruption in OpenGL homebrew. (this was a regression from removing sequence number increment from constant buffer update - another unrelated resource thing)
* Add tests.
* Add XML docs for GpuRegionHandle
* Skip UpdateProtection if only precise actions were called
This allows precise actions to skip reprotection costs.
When a texture is deleted by falling to the bottom of the AutoDeleteCache, its data is flushed to preserve any GPU writes that occurred. This ensures that the data appears in any textures recreated in the future, but didn't account for a texture that already existed with a copy dependency.
This change forces copy dependencies to complete if a texture falls out from from the AutoDeleteCache. (not removed via overlap, as that would be wasted effort)
Fixes broken lighting caused by pausing in SMO's Metro Kingdom. May fix some other issues.
* Store constant `Operand`s in the `LocalInfo`
Since the spill slot and register assigned is fixed, we can just store
the `Operand` reference in the `LocalInfo` struct. This allows skipping
hitting the intern-table for a look up.
* Skip `Uses`/`Assignments` management
Since the `HybridAllocator` is the last pass and we do not care about
uses/assignments we can skip managing that when setting destinations or
sources.
* Make `GetLocalInfo` inlineable
Also fix a possible issue where with numbered locals. See or-assignment
operator in `SetVisited(local)` before patch.
* Do not run `BlockPlacement` in LCQ
With the host mapped memory manager, there is a lot less cold code to
split from hot code. So disabling this in LCQ gives some extra
throughput - where we need it.
* Address Mou-Ikkai's feedback
* Apply suggestions from code review
Co-authored-by: VocalFan <45863583+Mou-Ikkai@users.noreply.github.com>
* Move check to an assert
Co-authored-by: VocalFan <45863583+Mou-Ikkai@users.noreply.github.com>
Seems like this is used as an optimized way to clear memory in homebrew applications. Unfortunately, calling the software fallback method every 8 bytes was not very optimal.
The existing EmitStore is used by passing in ZR as the register to get a 0 write.
This PR stubs and implements some clkrst call because they are used to overclock the Switch hardware and it's pointless in our case as we emulate the system.
Everything was done checked by RE.
Fixes#2686
Fix an issue introduced in #2190 where by 2 different count table entry
addresses were used for LCQ functions. E.g:
```asm
.L1:
mov rbp,COUNT_TABLE_0 ;; This gets an address.
mov ebp,[rbp]
lea esi,[rbp+1]
mov rdi,COUNT_TABLE_1 ;; This gets another address.
mov [rdi],esi
cmp ebp,64h
je near .L34
```
This caused LCQ functions to not tier up when they're loaded from the
PTC cache. This does not happen when they're freshly compiled.
This PR fixes the issue by ensuring only a single counter is created per
translation.
This PR stubs some irs service calls which are needed to get some games playable or at least bootable since we don't support IR data throught real JoyCon for now.
- Stubs `IIrSensorServer` `StopImageProcessor`, `RunMomentProcessor`, `RunClusteringProcessor`, `RunImageTransferProcessor`, `GetImageTransferProcessorState`, `RunTeraPluginProcessor`. All calls are a bit checked by RE.
Closes#2267, #2248, #2126
Night Vision and SpyAlarm are now bootable (but still unplayable due to the lack of the IR data):
* Fast path for Inline2Memory buffer write
This PR adds a method to PhysicalMemory that attempts to write all cached resources directly, so that memory tracking can be avoided. The goal of this is both to avoid flushing buffer data, and to avoid raising the sequence number when data is written, which causes buffer and texture handles to be re-checked.
This currently only targets buffers, with a side check on textures that falls back to a tracked write if any exist within the target range. It's not expected to write textures from here - this is just a mechanism to protect us if someone does decide to do that. It's possible to add a fast path for this in future (and for ShaderCache, once that starts using tracking)
The forced read before inline2memory begins has been skipped, as the data is fully written when the transfer is completed anyways. This allows us to flush on read in emergency situations, but still write the new data over the flushed data.
Improves performance on Xenoblade 2 and DE, which was flushing buffer data on the GPU thread when trying to write compute data. May improve performance in other games that write SSBOs from compute, and update data in the same/nearby pages often.
Super Smash Bros Ultimate should probably be tested to make sure the vertex explosions haven't returned, as I think that's what this AdvanceSequence was for.
* ForceDirty before write, to make sure data does not flush over the new write
* Array based RangeList that caches Address/EndAddress
In isolation, this was more than 2x faster than the RangeList that checks using the interface. In practice I'm seeing much better results than I expected. The array is used because checking it is slightly faster than using a list, which loses time to struct copies, but I still want that data locality.
A method has been added to the list to update the cached end address, as some users of the RangeList currently modify it dynamically.
Greatly improves performance in Super Mario Odyssey, Xenoblade and any other GPU limited games.
* Address Feedback
* vi: Unify resolutions values and accurate implementation of them.
To continue what was made in #2618, I've REd `vi` service a bit. Now values and checks related to displays are more accurate.
- `am` GetDefaultDisplayResolution / GetDefaultDisplayResolutionChangeEvent have more informations on what the service does.
- `vi:u/vi:m/vi:s` GetDisplayService are now accurate.
- `IApplicationDisplay` GetRelayService, GetSystemDisplayService, GetManagerDisplayService, GetIndirectDisplayTransactionService, ListDisplays, OpenDisplay, OpenDefaultDisplay, CloseDisplay, GetDisplayResolution are now properly implemented.
- Some other calls are cleaned or have extra checks accordingly to RE.
Additionnaly, `IFriendService` have some wrong aligned things, and `pm:info` service placeholder was missing.
* just use _openedDisplayInfo.Remove()
* use context.Memory.Fill()
* fix some casting
* remove unneeded comment
* cleanup
* uses TryAdd
* displayId > ulong
* GetDisplayResolution > ulong
* UL
* Disable Pause/Resume menu instead of trying to hide them
* Fix Resume menu being active before renderer starts
* Fix emulator not being able to close properly
* hos: Cleanup the project
Since a lot of changes has been done on the HOS project, there are some leftover here and there, or class just used in one service, things at wrong places, and more.
This PR fixes that, additionnally to that, I've realigned some vars because I though it make the code more readable.
* Address gdkchan feedback
* addresses Thog feedback
* Revert ElfSymbol
We currently use the FileChooser from GTK, which is a bit mess. Instead of it we could use the native FileChooser from all specifics OS. This is what this PR attempt to fix.
It could be nice to get a test under linux since I've only tested it under Windows without any issues.
Fixes#2584
* Refactor `PtcInfo`
This change reduces the coupling of `PtcInfo` by moving relocation
tracking to the backend. `RelocEntry`s remains as `RelocEntry`s through
out the pipeline until it actually needs to be written to the PTC
streams. Keeping this representation makes inspecting and manipulating
relocations after compilations less painful. This is something I needed
to do to patch relocations to 0 to diff dumps.
Contributes to #1125.
* Turn `Symbol` & `RelocInfo` into readonly structs
* Add documentation to `CompiledFunction`
* Remove `Compiler.Compile<T>`
Remove `Compiler.Compile<T>` and replace it by `Map<T>` of the
`CompiledFunction` returned.
