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.