cb1ec9a7f4
This commit encapsulates a complex sequence of cascading changes in the process of supporting overlaps for buffers: * We determined that it is impossible to resolve overlaps with multiple intervals per buffer within the constraints of each overlap being a contiguous view, support for multiple intervals was therefore dropped. The older buffer manager code was entirely reworked to be simpler due to only handling one interval per buffer with code now being based off `IntervalMap` but tailored specifically for buffers. * During overlap resolution, the problem of how existing views into the buffer being recreated would be updated, it had to be replaced with a larger buffer that could contain all overlaps and all existing views would need to be repointed to it. This was addressed by a buffer owning all views to itself, we could automatically recalculate the offset of all views and update the buffers with it. * We still needed to update usage of existing views which was done by handling all access (such as inside a recorded draw) to buffer view properties via `BufferView::RegisterUsage` which dispatches a callback with the view and the corresponding backing buffer. This callback can be stored and called during overlap resolution with the new buffer. * We had issues with lifetime of the buffer with the handle-like semantics of `BufferView` introduced in the last buffer-related commit, if we updated the view to be owned by a new buffer we'd need to extend the lifetime of the new buffer not the older one and the only way to do this was a proxy owner object `BufferDelegate` which holds a shared pointer to the real `Buffer` which in-turn holds a pointer to all `BufferDelegate` objects to update on repointing. A `BufferView` is effectively just a wrapper around `std::shared_ptr<BufferDelegate>` with more favorable semantics but generally just forwarding calls. It should be additionally noted that to support usage of `RegisterUsage` the code around buffers in `GraphicsContext` was refactored to defer truly binding till the recording phase. |
||
---|---|---|
.github/workflows | ||
.idea | ||
app | ||
gradle/wrapper | ||
.gitignore | ||
.gitmodules | ||
build.gradle | ||
BUILDING.md | ||
CONTRIBUTING.md | ||
gradle.properties | ||
gradlew | ||
gradlew.bat | ||
LICENSE.md | ||
README.md | ||
settings.gradle |
Contributing Guide • Building Guide
Skyline is an experimental emulator that runs on ARMv8 Android™ devices and emulates the functionality of a Nintendo Switch™ system, licensed under Mozilla Public License 2.0
Contact
You can contact the core developers of Skyline at our Discord. If you have any questions, feel free to ask. It's also a good place to just keep up with the emulator, as most talk regarding development goes on over there.
Special Thanks
A few noteworthy teams/projects who've helped us along the way are:
-
Ryujinx: We've used Ryujinx for reference throughout the project, the accuracy of their HLE implementations of Switch subsystems make it an amazing reference. The team behind the project has been extremely helpful with any queries we've had and have constantly helped us with any issues we've come across. It should be noted that Skyline is not based on Ryujinx.
-
yuzu: Skyline's shader compiler is a fork of yuzu's shader compiler with Skyline-specific changes, using it allowed us to focus on the parts of GPU emulation that we could specifically optimize for mobile while having a high-quality shader compiler implementation as a base. The team behind yuzu has also often helped us and have graciously provided us with a license exemption.
-
Switchbrew: We've extensively used Switchbrew whether that be their wiki with its colossal amount of information on the Switch that has saved us countless hours of time or libnx which was crucial to initial development of the emulator to ensure that our HLE kernel and sysmodule implementations were accurate.
Disclaimer
- Nintendo Switch is a trademark of Nintendo Co., Ltd
- Android is a trademark of Google LLC