# oboromi emulates a GPU by translating SASS to Vulkan

> oboromi is a work in progress Rust emulator foundation for the Nintendo Switch 2 that models an 8-core ARMv8 CPU, 12 GB of shared memory and a stub SM86 GPU, with the graphics path recompiled rather than interpreted. It cannot run commercial games or firmware yet, which the README states plainly, and the repository ships documentation rather than a usable emulator.

**0xNikilite/oboromi** — a proof-of-concept project for a possible Nintendo Switch 2 emulator.

- Repository: https://github.com/0xNikilite/oboromi
- Stars: 1,316 · Forks: 59
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-17 · Updated: 2026-10-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/0xnikilite-oboromi

## What the hardware model claims to be

The README describes oboromi as a WIP emulator for the Nintendo Switch 2, written in Rust, written lowercase, and it states the target hardware explicitly: an 8-core ARMv8 CPU, 12 GB of shared memory, and an SM86 stub GPU, where SM86 is the NVIDIA Ampere architecture.

Then comes the sentence that should lead any evaluation: it cannot run any commercial games nor firmware at this stage.

That is an unusually direct scope statement, and it means the repository should be judged on the fidelity of its components rather than on whether it plays anything. A CPU model with no usable software to run is a research artefact; a GPU translation pipeline with no games is a compiler.

The architecture is described as a foundation rather than a product, and the name is a constructed Japanese neologism combining oboro, meaning hazy or vague, with mi, meaning essence or fruit, giving what the README glosses as the tangible essence of imperfection. The author adds that even if finished it could never be perfect, and frames that as what it means to be an emulator.

The topic tags agree with the prose: emulator, proof-of-concept, switch2 and wip.

## The core library is split by subsystem

The `core` library is a directory of subsystems rather than a single module, and the split is the clearest statement of scope in the repository.

`audio` covers sound output. `fs` is a filesystem VFS, with the author noting it would probably emulate a 32 GB UFS or eMMC device to start with, which is a guess about the console's storage rather than a measurement.

`gpu` is the substantial one and is where the interesting problem lives. The README lists Ampere SM86 GPU emulation or recompilation, SASS to SPIR-V conversion, and transliteration into Vulkan with constants and a register map. That third item is the key design decision: instead of interpreting GPU instructions, the project compiles them into compute shaders that a Vulkan driver can execute. The register map and constant handling are what make that translation faithful rather than approximate.

`nn` is described as high-level emulation of firmware, so the neural network or system firmware interfaces are stubbed rather than implemented. `sys` holds the entire emulation state, which reads like a single top-level struct owning every subsystem, and `tests` sits alongside it.

The `docs` directory contains `sm86.pdf`, described as an autogenerated SM86 instruction set document with coloured table diagrams. An instruction set document generated from the same source the decoder is generated from is worth more to a reader than any hand-written summary, and it is what you would open first.

## Where the instruction data comes from

The `scripts` directory explains how the emulator knows what instructions exist. There is `decoder_generator.rs`, which generates parser code from the SM86 descriptions, and two data files: `sm_86_instructions.txt`, described as an instruction dump, and `sm_86_latencies.txt`, holding instruction latencies. Both are attributed to DocumentSASS, a separate project.

So the pipeline is: obtain an instruction and latency dump from DocumentSASS, run the generator, and get a decoder that the emulator core uses. 

It also means the project's accuracy is bounded by an upstream dump it does not own. If a revision is missing or wrong, the generated decoder inherits that, and there is no test suite described in the README that would catch it.

Two more directories deserve a note. `benchmarks/` exists at the root with no description in the README, which suggests performance work is under way but undocumented. `examples/` contains only a `.gitkeep`, so there are no example programs to run, which is consistent with the statement that no commercial games run.

## Two build systems and a UI that changed

The build configuration is small enough to read in full. The Cargo workspace declares resolver 3 with a single member:

```toml
[workspace]
resolver = "3"
members = [
  "core",
]

[workspace.dependencies]
log = "0.4"
```

A single member with one shared dependency is a very early-stage shape. Most of the intended crate structure is described in the README but not yet present as workspace members, so the plan in the prose is ahead of the manifests.

There is also a `CMakeLists.txt` at the root alongside `Cargo.toml`, which suggests parts of the project are built outside Cargo. For a pure Rust project that is an odd pairing and it is unexplained in the README, so anyone picking this up should expect to read the build files before assuming `cargo build` covers everything.

The README describes a simple eframe based interface for debugging, while the repository root has a `gui-qt/` directory.

The repository also has `CONTRIBUTING.md`, `assets/`, `docs/`, `license.txt`, and a `.gitmodules` file, which implies at least one component is pulled in as a submodule.

## Version history and what a tag name suggests

There are two releases: a pre-release v0.0.0 on 2025-07-15 and v0.0.1-dynarmic on 2025-10-12. The last push was on 2026-09-07 and the repository is not archived.

The gap between the most recent tag in October 2025 and the last push in September 2026 suggests work continued without a release, which is normal for an emulator foundation where the interesting commits are large internal refactors rather than usable states.

The licence is GPL-3.0, with a `license.txt` at the root and a GPL v3 badge in the README. For a project in this space that is the expected and appropriate choice.

The realistic assessment is straightforward. This is a well-organised skeleton with an unusually candid README, a code-generation pipeline for the hardest subsystem, and no ability to run anything yet. Its value to most engineers is as a worked example of how to structure a modern console emulator and how to translate an undocumented GPU instruction set onto Vulkan.

## Conclusion

Adopt this repository only as a reference for how a modern console emulator is structured, particularly the instruction decoding and shader translation pipeline, since it is not usable as an emulator. Do not plan any project that depends on it running games, because the README states plainly that it cannot run commercial games nor firmware at this stage. Verify first that the documentation generation step has been run against the current instruction dump, and note that the Cargo workspace currently contains a single member, core, so treat the layout as moving.

## FAQ

### Can oboromi run Nintendo Switch 2 games?

No. The README states plainly that it cannot run any commercial games nor firmware at this stage. It is described as a work in progress emulator foundation rather than a usable emulator.

### What hardware does oboromi emulate?

An 8-core ARMv8 CPU with 12 GB of shared memory and an SM86, meaning NVIDIA Ampere, stub GPU. The filesystem subsystem would probably emulate a 32 GB UFS or eMMC device to start with.

### How does oboromi handle GPU instructions?

It recompiles rather than interprets them, converting SASS to SPIR-V and transliterating into Vulkan with constants and a register map. The decoder itself is generated from an instruction dump by scripts/decoder_generator.rs.

### What is oboromi written in and how is it built?

It is written in Rust, with a Cargo workspace using resolver 3 that currently declares only the core member and a shared log dependency. A CMakeLists.txt also exists at the repository root, so the build is not purely Cargo-based.

## Sources

- [0xNikilite/oboromi on GitHub](https://github.com/0xNikilite/oboromi)
- [Issues](https://github.com/0xNikilite/oboromi/issues)
- [License: GPL-3.0](https://github.com/0xNikilite/oboromi/blob/main/LICENSE)
- [README](https://github.com/0xNikilite/oboromi/blob/main/README.md)
- [Releases](https://github.com/0xNikilite/oboromi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xnikilite-oboromi