The development team behind Eglantine, an experimental emulator for the Nintendo Switch 2, reports that Mario Kart World can run at full speed depending on a PC's hardware and settings. However, this only means the game can sometimes process at its intended speed. It does not guarantee that every scene renders correctly or that play is stable. No results measured under standardized conditions, such as average or minimum frame rates, have been published so far.
In late October 2026, a related upstream project released experimental Switch 2 support, and a separate fork added a fix that improves how GPU video memory (VRAM) is managed. Eglantine itself also fixed a bug in which an interrupted cache save caused startup failures on later launches. On October 31, a fix for a rendering glitch on AMD GPUs was merged as well. Development appears to be moving from simply getting games to run toward improving rendering accuracy and long-term stability.
Mario Kart World runs at full speed, with caveats
The official Eglantine README states that Mario Kart World runs at good or full speed depending on PC performance and settings. It does not give the CPU or GPU used, average or minimum frame rates, or results from extended testing across all courses. A game compatibility list is also planned for the future, so the full-speed claim should not be read as meaning the game plays smoothly across a wide range of PCs.
Eglantine is an open-source project based on the Nintendo Switch emulators Eden, Yuzu and Sudachi. It offers builds for Windows, Linux and macOS, but there is no confirmation that Switch 2 games run equally well on each operating system. Meanwhile, the eden-nx2 release page by Takoroka, which Eglantine draws on, published experimental Switch 2 support for Eden on October 29. The developer acknowledges that many fixes are still needed and says reliable testing outside Windows has not been possible.
The Windows build of eden-nx2 lists these requirements: 64-bit Windows 10 or 11, the Microsoft Visual C++ Redistributable (x64), a Vulkan-capable GPU with at least 8GB of VRAM, and at least 16GB of system RAM. These apply to that project's Windows distribution, not to Eglantine on every OS, and a PC that meets them is not guaranteed to run the game stably.
Rendering is also unfinished. The eden-nx2 developer explains that some shaders, the programs that run on the GPU, are not yet implemented, causing meshes that make up the shapes of 3D models to go missing. A pre-release of Eglantine-MKW dated October 30, another derivative project, also lists known issues: demanding courses can drop below 60fps, and brief stutters occur the first time a course is run.
In other words, whether the game runs at full speed, whether the screen renders correctly, and whether it stays stable over long sessions each need to be judged by separate criteria. The reports and fixes published as of late October break down as follows.
| Criterion | Published reports and fixes | Scope and caveats |
|---|---|---|
| Speed | Runs at full speed depending on PC hardware and settings; demanding courses reportedly fall below 60fps | Separate reports from the Eglantine and Eglantine-MKW developers, not a comparison under shared conditions |
| Rendering accuracy | Missing geometry from unimplemented shaders and rendering glitches on AMD GPUs have been confirmed | Upstream project explanation and Issue #59; a fix for the latter was merged on October 31 |
| Stability | VRAM management improvements and a fix preventing startup failure after an interrupted cache save | The VRAM fix was tested in a simulation on Eglantine-MKW; the cache fix was tested with a restart test on an M1 Pro in Eglantine itself |
These reports show that frame rate alone cannot gauge an emulator's maturity. A game can run at full speed while parts of 3D models fail to appear, or while insufficient VRAM breaks rendering. Even if a game exits normally, a failure on the next launch makes continued use difficult. Turning full-speed operation into stable play requires solving each of these problems individually.
Why problems occur even with 8GB or more of VRAM
Eglantine-MKW, developed by Wael3rd, is a separate derivative of Takoroka's eden-nx2. Its October 30 pre-release targets Mario Kart World version 1.8.0 and recommends Vulkan rendering at 1x resolution. Recommended settings also include enabling asynchronous shaders and BC3 recompression, which reduces texture memory use. However, fixes implemented in this fork are not necessarily reflected in every build of Eglantine itself.
A technical document on VRAM published by the project's developer explains in detail the cause of texture corruption and crashes on AMD GPUs. One factor was memory management when handling ASTC-format textures on the GPU. ASTC is a texture compression method, and when a GPU cannot handle the format natively, the decompressed image data must be placed in memory. Keeping textures uncompressed increases VRAM consumption, making memory shortages more likely, especially on GPUs with less capacity.
The problem found in Eglantine-MKW, however, was not simply that textures were large. The emulator was also overestimating the VRAM actually available. GPU memory management treats different kinds of memory regions as "heaps," and on AMD GPUs several heaps can share the same physical VRAM. The earlier implementation summed the available budget of each heap, double-counting shared VRAM and overestimating usable capacity.
For example, on an 8GB RX 9060 XT, available VRAM was reported as about 7GiB, yet the texture cache's management limit was set above that. The emulator judged that free space remained and tried to allocate textures that did not fit in actual memory. As a result, parts of images were left without allocated memory, leading to texture corruption and crashes.
The fix replaces the simple summing of heap budgets with the actual budget the driver reports for the GPU's main device-local memory region. For Switch 2 workloads, the emulator also checks the memory budget every 30 frames and updates the texture cache's management threshold. Specifically, it reserves headroom equal to the smaller of one-eighth of the budget and 1GiB, and prompts memory reclamation once usage reaches a set threshold. This tidies up the texture cache before it exceeds what can actually be allocated.
In addition, automatic BC3 texture recompression was introduced for GPUs with limited capacity. The switch happens when the GPU lacks native ASTC support, the VRAM budget obtained at startup is under 12GiB, and the recompression setting is set to uncompressed. When these conditions are met, BC3 is used for that session. Because the criterion is the memory budget the driver reports at startup rather than the GPU's nominal VRAM, it does not simply mean that every GPU under 12GB will switch.
The developer tested the fix by simulating an 8GB environment on a 16GB GPU. In a test with a 7GB memory limit, peak usage stayed at 6.6GB and no texture allocation failures occurred. Frame rates were reported to be equivalent to before the fix. This was a simulation on a restricted 16GB GPU, however, not broad testing on multiple real 8GB products.
The "8GB or more of VRAM" requirement from the upstream project should be distinguished from the results of this simulation. Even a GPU with the required VRAM can suffer rendering corruption or crashes if memory use during play exceeds a manageable range. The fix shows that stable operation depends not only on the VRAM a GPU carries but on the emulator correctly understanding and managing that capacity.
Fixes for AMD rendering glitches and a failure to restart
In Issue #59 of Eglantine itself, a user reported that running Mario Kart World on an AMD GPU displayed green-to-blue semicircular shapes under item boxes and around other karts. The reporter's setup was a Radeon RX 9070 XT 16GB, Core i5-14600KF, 16GB of RAM and Windows 11, running game version 1.8.0. The glitch appeared in a build named nx2-ea33ad1865, which includes custom changes to terrain rendering and similar elements, and reproduction on an official release was not confirmed. The reporter said toggling BC3 recompression on or off did not change the symptom, indicating a problem that reducing VRAM use alone could not solve.
For this glitch, pull request (PR) #89 was merged on October 31. The cause identified was a difference in how variables with undefined values are handled inside shaders. According to the fix's description, undefined values that NVIDIA GPUs treated as zero were processed as indeterminate values on AMD GPUs, producing bands of color that should not exist on roads and other surfaces. The fix absorbs the difference by replacing some instances of OpUndef, which represents an undefined value in SPIR-V, with zero.
PR #89 includes before-and-after comparison images and reports that the glitch was resolved. This is a fix for a specific bug, however, and does not guarantee complete rendering across AMD GPUs generally. Nor does a fix being merged into the source code mean it has reached every distributed build. Confirming the improvement requires using a build that includes the fix, reproducing the same scene, and checking for effects on other rendering.
Separately from rendering, a bug that prevented the emulator from restarting after being closed was also fixed. PR #29, merged into Eglantine on October 30, addresses a problem in which interrupting the process while a Vulkan pipeline cache is being saved leaves an empty cache file. When the emulator tries to load this file on the next launch, an exception occurs while reading the header. On macOS in particular, differences in the C++ standard library implementation meant the exception type did not match what was expected, and the emulator could terminate.
Once in this state, the invalid cache file remains, so the same error recurs on every launch. The fix changes the process so the cache is not overwritten directly: it is first saved to a temporary file and then swapped in for the existing one. Even if the emulator is force-quit during saving, the previous valid cache is preserved. It also treats a file shorter than the header as corrupt, deleting it and rebuilding the cache.
The developer confirmed on an Apple M1 Pro machine that force-quitting the emulator during a cache save and then restarting it succeeded. This was a test to eliminate startup failures caused by cache corruption, and it does not show that Mario Kart World runs at full speed on the M1 Pro. The cause and remedy also differ from rendering glitches caused by VRAM shortages or unimplemented shaders. Improving the emulator's stability requires resolving each of these problems separately.
Eglantine and its related projects are improving memory management, rendering and cache saving on top of the initial implementation that gets Switch 2 games running. Still, the developers' reports of full-speed operation alone do not show whether comfortable play is actually possible. Going forward, it will be important to standardize the emulator build, game version and settings such as resolution and texture compression, and to test sustained driving on demanding courses and restarting after exit. As reproducible results accumulate under such conditions, it will become possible to judge how close the current experimental operation is to practical compatibility.