Dolphin - Scalability

Dolphin is an emulator that lets users play GameCube (GC) and Wii games which is therefore highly dependent on the performance of the machine of the user. A significant reduction in resources will have an immediate effect on the application’s performance and thus the user experience. The big scalability challenge of Dolphin is increasing the performance of the application. Dolphin developers are always looking for a more efficient implementation or solution so the end-user can play the games at a desirable framerate without crashes.

Dolphin has a couple of recommended minimum requirements. It is recommended that the PC has at least a 3 GHz dual-core CPU not older than 2008¹. For the graphics card, a reasonably modern graphics card (Direct3D 10.0 / OpenGL 3.0) is minimal and support for Direct3D 11 / OpenGL 4.4 / Vulkan 1.1 is recommended. A PC should have at least 1 GB but preferably 4 GB of RAM or more.

In a plausible scenario where these minimum requirements are not met, Dolphin will have performance issues. A slow processor and graphics card will cause long loading screens and possibly a slowdown of the video or audio². Insufficient RAM will cause crashes and also longer waiting times as not the whole game can be stored in RAM.

To have a pleasant experience using Dolphin you also need sufficient storage space. The games that a user wants to play are not stored in some online database, but they are kept on the user’s system locally. The games are often larger than 1 GB and the saves are not small either. Nobody wants to delete and reinstall a game or start over every time because their disk is full, so quite some storage space is needed. To limit the total space, Dolphin itself should remain relatively small. This is something that can limit the scalability of Dolphin as constantly adding features can increase the size of the application.

Using Netplay, the user can play the emulated games with their friends online. A slow or unstable internet connection causes a high ping and unwanted WebSocket disconnects. This makes the multiplayer feature essentially unplayable for this user. With Netplay the required bandwidth also increases very fast the more players you want to connect with³. So scaling the number of players in one lobby could cause low performance and an unstable connection.

Another scalability challenge is platform-independence. The entire point of Dolphin is to not be locked down to a single platform to play games, so this is very important. Currently, Dolphin already supports Windows, Linux, macOS, and Android, but it should be ready to add support for future platforms. Support for some modern popular platforms is also still missing. The most obvious candidate platform is iOS, but other potential platforms to support are the Sony Playstation and Microsoft Xbox families, and the Nintendo Switch. Support for specific instances of a platform, such as the Steam Deck, could be part of this as well.

Finally, another plausible scenario is that Dolphin starts emulating a third console, for example, the Triforce. The Triforce is based on GC hardware, so it could reuse a lot of the existing code in Dolphin. Dolphin used to support it years ago, but it was removed because the implementation was flawed and no one was willing to maintain it anymore⁴. It is possible that, in the future, some Dolphin developers want to try it again. In that case, the new code needed to emulate the Triforce hardware and software is the scalability challenge. When the codebase is currently not able to deal with those kinds of new features, having to refactor all the code would probably be too much of an obstacle to implement a new emulation. This is why the codebase is part of the key aspects of the scalability of Dolphin.

Quantitative analysis of the runtime

We analyzed the performance of Dolphin under varying workloads. We used Dolphin Beta version 5.0-16101 on macOS using an ARM-based M1 chip. We used the Dolphin for emulating Super Smash Bros. Melee (USA) (EN, JA) (v1.01) (SSBM) in all our tests.

Using no limits, the CPU was used the most for the time to load the menu test for a maximum of 103,7%. After Dolphin is launched, only around 5% of the CPU is used. In an SSBM match, the CPU uses between 40% and 60% of its power. We can see that limiting the CPU usage has a significant effect on the loading screen time. Surprisingly, the game was not unplayable but worked pretty well with a couple of lag spikes.

At and after Dolphin’s launch, the RAM usage never goes beyond 100 MB. When starting the game, Dolphin’s RAM usage spikes up to 450 MB and stays around that size. In an SSBM match, Dolphin uses up to 600 MB of RAM. As expected, limiting the RAM did not affect the start time of Dolphin. For launching SSBM itself and a match, we had to tweak some settings to make it more lightweight. The time to load the main menu is noticeably slower with less RAM. The time to start a match is not that big of a difference. This is probably due to the fact that the GC and Wii only have a maximum RAM size of 64 MB⁵. The game itself does not require a lot of RAM, but Dolphin uses the majority. Starting the game, which will require Dolphin to set up an emulation environment, asks for the most RAM.

Architectural decisions that affect the scalability

Looking at the codebase, scaling Dolphin to include an emulation of another console does not seem to give many problems. The design choices for the menus, for example, display the different options for both the GC and Wii on different tabs. Therefore, adding a new console would just require a new tab in the settings window. Since the new console has its own settings, this new window would not suffer from code duplication etc. so it would scale well.

For game booting, one class is used with different methods for booting GC and Wii games. So extending this with a method for the new console would also scale well. Another part, the input mappings, also has independent code for each controller type, because each controller type has different forms of input. So again, extending for another console is just a matter of adding a new class; no refactoring needed as shown in the figure.

So the architectural decision of splitting the console-specific functions into separate classes while also having classes that do the common tasks seems like a good choice when looking at scalability. Especially since each emulated console has its own functionalities and requirements so it would be impossible to have a general class for all of them.

As for platform-independence, Dolphin separates the common core from the platform-specific code. This should make it easier for developers to add support for more platforms, as the common core can be reused.

Scalability of the Netplay system

The Netplay system of Dolphin has a few possible modes to support different types of games and different amounts of players. First of all, there is the standard peer-to-peer Netplay as shown in the figure. This works fine for lobbies of two players because of the synchronization. This also means that for more than two players, this synchronization gives too much overhead as the number of connections grows exponentially and games will not run smoothly if one of the players has even the smallest stutter.

To support those kinds of lobbies, the host input authority was made⁶. Here, all the inputs of players would go through the host which means everybody runs asynchronously as shown in the figure. The latency is handled automatically and is aimed to be as low as possible for everyone. When one of the players is desynced, the game would temporarily freeze for that player, but not for the others. This results in a much more smooth experience for larger lobbies since there is no more need for perfect synchronization.

Last but not least, Dolphin implemented a so-called golf mode⁷. Here, there is a host that throughputs all the inputs of all players and has no latency like the host input authority mode, but it is possible to switch who is the host which is nice for turn-based games. So the scalability of Dolphin in terms of online Netplay is pretty solid with different modes supporting different types of lobbies.

Changes for improving performance

One way to improve the performance of Dolphin is to implement DirectStorage. This is a low-level storage API, developed by Microsoft, that was recently released for PC and allows the GPU to load assets directly from disk. This would improve loading times, especially when HD textures are used. DirectStorage is benchmarked to increase file I/O speed by about 70% with its impact being a drastic reduction in loading times⁸.

Another way to improve performance is to implement a smart resolution upscaling technique. One such technique is NVIDIA Deep Learning Super Sampling (DLSS). It uses ray-tracing hardware in the graphics card to perform an AI upscaling algorithm. This allows the video output to appear sharper than the actual resolution it was rendered at. The main downside of this technique is that it requires a modern graphics card that is capable of ray-tracing, which is already powerful enough to run Dolphin without upscaling. NVIDIA claims that the performance gains can be up to 3 times more⁹.

Another smart resolution upscaling technique is AMD Fidelity FX Super Resolution (FSR). This technique does not require ray-tracing hardware and is therefore useful for users with an older graphics card or Android users. Additionally, it could be used to upscale pre-rendered cutscenes in games, so users with more powerful hardware can benefit from it as well. FSR promises a 2.4× performance increase when running games at 4K resolution¹⁰.