Despite the trampoline size being hardcoded, it was previously dynamic and could change based off of the value stored in the target register potentially leading to instructions being missed.
The previous method would cause OOB reads for the last row to clamp, and adding an extra row would potentially encounter unmapped memory. So use this technique based on how Ryu does it.
These are mostly implemented how you would expect, however as opposed to copying out query pool results immeditely, doing so is delayed until the RP end in order to avoid splits.
The layout preview/editor doesn't instantiate an Application instance, therefore accessing `displayMetrics` from the app context would lead to a crash, and the view being mocked in the preview.
Additionally a default grid value is defined for `AlignmentGridView` to avoid a crash because of an invalid iteration step in the drawing loop.
As part of this commit, a `defaultEnabled` property was added to `OnScreenButton` to determine the default visibility of buttons. This is required because L3 and R3 should be hidden by default and only enabled by the user on demand.
Additionally, the buttons' mask values were added to `ButtonId` members, as adding entries in the middle of the class conflicted with the `ordinal` enum property, making it unfit to use for our purposes.
Finally, the `ControllerType` class was extended with an array of optional buttons. Optional buttons represent buttons that are allowed to be displayed on screen, but shouldn't be included in the controller mapping activity.
Edit mode configuration parameters are now shared between the view and the buttons in a small `OnScreenEditInfo` object, avoiding variable duplication about edit state. The `editingTouchHandler` has also been simplified to only lookup the button if one wasn't being edited already.
The yuzu audio_core code is mostly untouched, with a set of wrappers used to bridge it with skyline kernel primitives. Huge thanks to maide and their advice, whom without this wouldn't have been possible.
`PreferenceDialogFragment`s have been extended to use `MaterialAlertDialogBuilder`, which results in Material Design 3 dialogs. `DialogFragment` creation logic has been moved to `SettingsActivity` to reduce code duplication.
Now usagetracker is properly in place, indirect draw HLE can be used without requiring any hacks. Dirtiness is now ignored when fetching macro arguments, and it's now the duty of the HLE impls themselves to perform flushing if they require it.
This still requires usagetracker to avoid redundantly performing indirect draws when the memory isn't dirty, and to allow for using it with direct memory, but it's a start.
Indirect draws are implemented by having the macro arguments overflow into a seperate GP Entry that points directly to the indirect argument buffer. To HLE indirect draws a buffer needs to be created from this pointer, and it cannot be dereferenced on the CPU at any point to avoid hitting traps.
In the cases of indirect draws, we don't know the vertex offset to write into the driver info constant buffer ahead of time, and to do it at draw time on the GPU would mean marking the constant buffer as GPU dirty (slow). HLE them in the shader instead using the host draw parameters extension.
When GPU crashes aren't reproducable in renderdoc, it helps to have someway to figure out what exactly is going on when a crash happens or what operation caused it. Add a checkpoint system that reports the GPU execution state in perfetto in time with actual GPU execution, and use flow events to show the event's path through execution, vulkan record and executor record stages.
This is neccessary as e.g. shaders can be updated through a mirror and never hit modification traps. By tracking which addresses have sequenced writes applied, the shader manager can then correctly detect if a given shader has been modified by the GPU.
`One missing Bitmap to rule them all and one condition to find them.` Also eliminates passing that condition between methods. The data class can simply return the same instance every time it's necessary.
Since this is instantiated in `onCreate` and may be recycled with different settings, relying on the audio to be disabled to determine if a mute action is available seems like a risky gamble.
This should adapt to the package name, despite not actually relying on the value of it to function. Intents are one of the most analyzed items for vulnerabilities and exploits.
Some games, for example PGLE, have heavy contention in code that locks mutexes for only a brief period of time. This heavy contention over multiple threads results in futex latency (often ~20us) impacting performance heavily. Using an adaptive condition variable helps to reduce this latency.
By spin waiting for a small period before falling back to an actual condition variable, some of the overheads inherent to futex's can be avoided. The used constants were tuned for optimal performance on 8G1 on Skyrim and PGLE.
