deko3d backend on another Aurora game (Twilight Princess) — results and a few questions

[Alexgg1014]

Hi! I maintain Dusklight for Switch, a port of the Twilight Princess decomp on Aurora. Our Aurora shares your base (encounter/aurora 3227d76) and currently uses Dawn on Vulkan (Mesa NVK). We're planning an optional, experimental deko3d backend based on yours (MIT, with credit; the MPL-2.0 files from SwitchWakerHD kept separate and unmodified).

First, something back: your native/tools/dksh_cache builds against our Aurora with almost no changes (no draw census; three timing counters stubbed). We ran it on our pipeline list: 6,776 / 6,776 GX configs plus 56 fixed entry points compile, with 0 Tint or uam failures and 0 uam warnings. It takes about 65 s on 20 CPUs, and the output is byte-identical across two runs (13.5 MiB). Your two Tint patches apply in order on Dawn 1155e0ed. Thanks for documenting it so well.

A few questions, if you have time:

1. RmlUi: your build disables it. Have you tried RmlUi on deko3d, or do you know of a blocker? Our menus are RmlUi, so for us it's the biggest missing piece.
2. Upstream: do you plan to propose the deko3d backend to encounter/aurora? A shared upstream would let several games maintain it together.
3. License headers: the MIT files (e.g. switch/deko/aurora/*, shader_translate.*) have no SPDX header, while the MPL ones do. Would you be open to adding SPDX-License-Identifier: MIT? It makes attribution unambiguous for anyone reusing them.
4. Runtime selection: you select the backend with AURORA_GFX_DEKO3D at build time. Did you consider one NRO that picks Dawn or deko3d at startup? Did anything (the --wrap shadows, memory) make you rule it out?
5. Review and tests: which parts of the backend have been reviewed by people, and which tests exist beyond the DKSH round-trip?
6. Memory: could you share how the ~250 MiB of deko3d startup memory breaks down, compared with Dawn's staging buffers? We also have a render-target pool for dynamic resolution and a second window.

Happy to share our measurements (per-thread frame times and GPU timings on NVK) if they're useful for comparison.

[Pulpparty]

Hi, and thanks for the detailed write-up! Good to see dksh_cache carrying over to another Aurora game: 6,776 / 6,776 configs with zero failures and byte-identical output is a nice confirmation.

1. RmlUi: we haven't tried it. We don't know of a hard blocker, but today dk_encode.cpp only encodes GX draws and clears; DrawKind::Other and CustomDraw commands are skipped and logged once. RmlUi would need its own encode path and pipeline creation, plus its shaders in dksh_cache.

2. Upstream: not for now. The backend leans on Dawn's Null device and on linker --wraps, which is not the shape upstream would want, and we'd rather not take on tracking Aurora's head yet. Medium term, though, we're open to pulling the common parts (the deko3d backend, our vendored deko3d/uam with their patches, the Aurora and Tint patches, dksh_cache) into a shared repo that several ports could use. If Dusklight goes ahead with deko3d, that would be a good reason to do it. Tracking it in Extract the deko3d backend into a shared repo for other Aurora ports #33, and you're welcome to comment there.

3. SPDX: good point, done. Our MIT files in switch/deko, switch/deko/aurora and native/tools/dksh_cache now carry SPDX-License-Identifier: MIT. The MPL-2.0 files adapted from SwitchWakerHD keep their own notice.

4. Runtime selection: we didn't pursue it, because we dropped the GL NRO entirely and deko3d is our only Switch renderer. The --wrap shadows (12 wgpu* create/addref/release functions in dk_objects.cpp) forward to __real_*, so they could be gated at runtime. The costs we'd expect: Mesa back in the binary (16.2 → 21.6 MB for us), Tint's y-up patch being deko3d-only (we build that NRO against its own Dawn source), and our Aurora patch 0013 requesting Dawn's Null device. Memory would also be tight with both stacks' buffers around.

5. Review and tests: Every change to the backend is reviewed by the maintainers before it is merged, and each one is checked on hardware before it lands in a release. On the console, that meant an A/B against the old GL renderer on six scenes (fps, GPU time, per-draw CPU), comparing captures, and 25–30 minute warp tours with no deko3d error and stable memory. On the build side, dksh_cache check makes sure every fixed shader the NRO uses is in the cache, and the cache build is deterministic, as your two byte-identical runs also show. Our Mac regression suite (native/tools/regress.sh) covers the game but not deko3d, because the Mac build uses Dawn. There are no automated unit tests for the backend itself.

6. Memory: the ~250 MiB figure is from SwitchWakerHD. Here, Aurora's staging slots become 3 × 63 MiB deko3d blocks that the GPU reads in place, instead of Dawn's 5 × 63 MiB plus copies. On top of that: stream 3 × 8 MiB, command 3 × 4 MiB, code 32 MiB (the DKSH, bump-allocated), image heap in 64 MiB chunks (first-fit, one allocated at start), 8192 image + 1024 sampler descriptors, and small query/queue blocks (switch/deko/dk.h). On the console, heap free after init was 123.2 MiB on both deko3d and GL. For a render-target pool and a second window, the image chunks are where that would land.

Your NVK per-thread frame times and GPU timings would be very welcome for comparison.

[Pulpparty]

Just saw v1.0.0 is out with deko3d as the default, congratulations, and thanks for the credit! Since a second port now runs this backend, #33 (a shared repo for the common deko3d/Aurora parts) is no longer hypothetical. If you're interested, we'd be glad to compare notes there, in particular on how you got RmlUi and the runtime Vulkan/deko3d switch working.

[Alexgg1014]

Thanks a lot, and thanks again for SwitchWakerHD, the backend wouldn't exist without it!

Yes, I'm interested in #33. Sharing the common deko3d/Aurora parts makes a lot of sense now that two ports run it.

Quick summary of the two things you asked about, and I can write up the details in #33:

• RmlUi: it goes through Aurora's normal pipeline path, so on deko3d its geometry/texture pipelines are built like any other Aurora pipeline, with precompiled DKSH from the shader cache. ImGui and text use a few small embedded DKSH shaders.
• Vulkan/deko3d switch: it's a setting read at boot (Settings > Graphics Backend), applied on the next start. deko3d is the default; Vulkan (Dawn) stays as the fallback. Mods that draw through the gfx service still need Vulkan for now, and the game offers to restart into Vulkan when one is enabled.

I'll also share the console frame times and GPU timings you asked for.