Booting a Switch 2 emulator in half the time: what the boot marks found

Why boot time is worth a post

On a laptop or a handheld, boot is something you sit through every time: every launch, and every restart after you change a setting or a switch. The project's rule is that a change ships only with a measured gain. Boot time gets the same treatment, which meant measuring it properly first.

What the boot marks are

v20 already logs coarse boot events. Set EDEN_NX2_STUTTER_TRACE=1 and the log gets Nx2Boot lines for the start of the boot, the shader cache load, precaching and the first frame, with memory commit next to each. That tells you how long the boot took, but not where the time went.

The finer boot marks, in a work branch and not in v20 yet, log each phase as Boot timing: <phase> at <milliseconds since the process started>, and many phases also carry their own duration. They cover:

• the frontend: logging, the main window, content providers and the game list scan, and the list of Vulkan devices for the settings;
• the game boot: the boot request, settings, and the core load, from system setup through the GPU and renderer, the kernel and the application process;
• Vulkan: listing instance extensions and layers, creating the instance, enumerating physical devices and creating the device;
• the game's file system: building the RomFS tree, the RomFS patch and LayeredFS for mods;
• the disk shader cache load that gates the start of the guest;
• the first guest frame on screen.

The same change also logs the present mode of every swapchain the emulator creates, which feeds the frame pacing work.

What they found

In one traced boot of 24.7 s, about 11 s was Vulkan instance creation. That is a single phase, and it runs before the game has drawn anything.

We have not split those 11 s yet, so we do not know their cause, and we will not guess in public. What we do know is where to look. Instance creation is the step where the Vulkan loader finds the installed drivers and loads them, together with any layers registered on the system, so that is where the next, finer marks go.

The boot also reaches Vulkan more than once: the frontend lists Vulkan devices for its settings page, and the renderer creates its own instance. Whether one of those or both are slow is the next thing to measure.

What is being cut

These are the options being measured, not results:

• Split the 11 s. Marks inside instance creation: loading drivers, layers, extension queries.
• Do not pay for it twice. If the frontend's device listing and the renderer each create an instance, share the work or move the listing off the boot path.
• Overlap it. Start Vulkan setup alongside boot work that does not need the GPU, such as reading the game's file system and the shader cache files.

Each lands only with boot marks from the same machine, before and after, and with the game reaching gameplay unchanged.

The rest of the boot

Other boot work is already written up as agent-ready issues, each with a test that runs without the game:

• #12: parse the game's container once per boot instead of more than once, and account for the time before the RomFS patch.
• #11: memory-map the shader cache, decode its programs in parallel, then let the game reach its first frame while the rest of the cache loads.
• #10: persist translated SPIR-V, so a restart does not translate every shader again.

The roadmap groups these with non-blocking boot and memory-mapped caches.

Measure your own boot

1. Add EDEN_NX2_STUTTER_TRACE=1 to your nx2_switches.txt (the README says which copy to edit).
2. Boot the same game three times with a warm cache, and keep the Nx2Boot lines. python -I tools/nx2/cache_metrics.py parse <log> turns a log into JSON, and compare diffs two runs.
3. Post the numbers with your device, driver and storage in issue #11 or in a device report. Do not attach the log itself if it shows your user name or folder paths.

Questions people ask

Is boot time halved in v20?

No. v20 has the coarse Nx2Boot events. The finer marks and the cuts are still in progress, and "half" is the target we are working toward, not something we have measured.

Why does the first visit to an area hitch, even after the game has booted?

That is a different cost: the driver compiles each new shader pipeline the first time it is needed, and later visits load it from the cache. The FAQ explains it.

Will a faster SSD help?

We do not know yet. The marks separate file system and cache reads from GPU setup, so a report from a machine with different storage would answer it.