The overnight spike answered "how can frank-tts run on hardware instead of CPU?" — not on the Strix Halo NPU, and the wall is the loader, not the silicon. Docs only; the fleet is untouched and frank-tts / frank-tts-engine still serve narrator1|2|3 on CPU.
Pages
Page
Owns
report/tts-npu-spike-verdict-2026-10-19.md
the measured verdict: exoneration chain, both arms' real-time bars (12.5 codes/s deployed vs 50.00 for NuTTS-Air), the 65,536-entry speech-token census, host gates, the iGPU census + heap gate result, the five-file change surface
report/npu-tts-runtime-landscape-2026-10-19.md
which runtimes can reach XDNA2 on Linux at all (research slice; now points at the verdict)
what the payload is and where it can move (research slice; ANSWER C confirmed on the live host)
serverAppConfigs-docs/Dankclaw/Frank TTS.md
new Where the engine computes section, so a TTS task learns the NPU is a closed door without re-walking it
Findings worth a skim
NPU: NO-GO on a loader gate.xrt-smi validate PASSES incl. throughput, yet the RyzenAI EP opens /dev/accel/accel0, succeeds at the GEM ioctls, then declines the graph and emits zero log lines on every lever (GENAI_ORT_VERBOSE_LOGGING, set_log_callback, RYZENAI_EP_TRACING). One run loaded; byte-identical runs never reproduced it. No token rate is quoted because none was ever measured.
iGPU: heap gate PASSED.vulkaninfo in the engine's own base image reports DEVICE_LOCAL = 77.33 GiB (budget 65.16 GiB with frank-dragoon loaded) — Mesa splits the 116 GiB aperture ⅓/⅔ on APUs, so the 2 GiB DRM carve-out never enters the picture. Target shape is co-tenancy with frank-dragoon; the constraint is host RAM (17 GiB available; GTT pages are system pages) and shader time, not the aperture.
Two traps recorded:vulkaninfo --batch doesn't exist in Ubuntu 24.04's vulkan-tools (prints help, exits 1 — reads like a driver failure), and renderD128 on this hybrid box is the NVIDIA node — the iGPU is renderD129, so the quadlet must pass /dev/dri, not a guessed number.
Speech codebook is 65,536 (<|speech_N|>, ids 151,671–217,206), not the 10,001 an earlier note claimed.
Checks
./tests/run.sh450/450 green on each commit. No service restarted, no host state changed. Follow-on feat/frank-tts-vulkan (ordered by Frank) builds on this.
## What
The overnight spike answered "how can frank-tts run on hardware instead of CPU?" — **not on the Strix Halo NPU**, and the wall is the loader, not the silicon. Docs only; the fleet is untouched and `frank-tts` / `frank-tts-engine` still serve `narrator1|2|3` on CPU.
## Pages
|Page|Owns|
|---|---|
|`report/tts-npu-spike-verdict-2026-10-19.md`|the measured verdict: exoneration chain, both arms' real-time bars (12.5 codes/s deployed vs 50.00 for NuTTS-Air), the 65,536-entry speech-token census, host gates, the iGPU census + heap gate result, the five-file change surface|
|`report/npu-tts-runtime-landscape-2026-10-19.md`|which runtimes can reach XDNA2 on Linux at all (research slice; now points at the verdict)|
|`report/qwen3-tts-payload-portability-2026-10-19.md`|what the payload is and where it can move (research slice; ANSWER C confirmed on the live host)|
|`serverAppConfigs-docs/Dankclaw/Frank TTS.md`|new *Where the engine computes* section, so a TTS task learns the NPU is a closed door without re-walking it|
## Findings worth a skim
- **NPU: NO-GO on a loader gate.** `xrt-smi validate` PASSES incl. `throughput`, yet the RyzenAI EP opens `/dev/accel/accel0`, succeeds at the GEM ioctls, then declines the graph and emits **zero log lines** on every lever (`GENAI_ORT_VERBOSE_LOGGING`, `set_log_callback`, `RYZENAI_EP_TRACING`). One run loaded; byte-identical runs never reproduced it. No token rate is quoted because none was ever measured.
- **iGPU: heap gate PASSED.** `vulkaninfo` in the engine's own base image reports `DEVICE_LOCAL` = **77.33 GiB (budget 65.16 GiB with frank-dragoon loaded)** — Mesa splits the 116 GiB aperture ⅓/⅔ on APUs, so the 2 GiB DRM carve-out never enters the picture. Target shape is co-tenancy with `frank-dragoon`; the constraint is host RAM (17 GiB available; GTT pages *are* system pages) and shader time, not the aperture.
- **Two traps recorded:** `vulkaninfo --batch` doesn't exist in Ubuntu 24.04's `vulkan-tools` (prints help, exits 1 — reads like a driver failure), and **`renderD128` on this hybrid box is the NVIDIA node** — the iGPU is `renderD129`, so the quadlet must pass `/dev/dri`, not a guessed number.
- Speech codebook is **65,536** (`<|speech_N|>`, ids 151,671–217,206), not the 10,001 an earlier note claimed.
## Checks
`./tests/run.sh` **450/450 green** on each commit. No service restarted, no host state changed. Follow-on `feat/frank-tts-vulkan` (ordered by Frank) builds on this.
---
cwd: /home/blank/.omp/wt/wt-20261019-020309-6d1fc1f · session: 01a15366-7601-7175-bb69-c62186c3f8b5
The overnight spike settled whether frank-tts can run on the Strix Halo NPU.
It cannot, and the wall is the loader, not the silicon: AMD's own Linux
runtime opens /dev/accel/accel0, succeeds at the GEM ioctls, then declines
the NuTTS-Air graph without emitting a single log line — and the one run that
did load has never reproduced. The accelerator that does exist is the gfx1151
iGPU behind -DGGML_VULKAN=ON, a flag our own Containerfile.engine writes OFF,
and Frank set the target shape to co-tenancy: the engine resident beside
frank-dragoon, not a handover.
- report/tts-npu-spike-verdict-2026-10-19.md owns the measured result: the
exoneration chain, the two arms' real-time bars (12.5 codes/s deployed vs
50.00 for NuTTS-Air), the 65,536-entry speech-token census (ids
151,671-217,206), the host gates (rootless cannot read accel0; dpkg-deb the
vendor XRT, never dpkg -i), the iGPU census (18,523 of 116,733 MiB GTT in
use, 17 GiB host RAM available, GTT pages are host pages), the two gates
that decide co-tenancy (RADV heap for an APU tenant; dragoon's TTFT with a
synthesis in flight), and the five-file change surface for the trial.
- report/npu-tts-runtime-landscape-2026-10-19.md and
report/qwen3-tts-payload-portability-2026-10-19.md are the research slices;
both now point at the verdict page instead of ending in loose ends.
- The vault page gains "Where the engine computes", so an operator doing a TTS
task learns the NPU is a closed door without re-walking it.
No fleet change: frank-tts / frank-tts-engine still serve narrator1-3 on CPU.
tests: ./tests/run.sh 450/450 green.
vulkaninfo inside the engine's own base image (ubuntu:24.04 + mesa-vulkan-drivers
vulkan-tools, --device /dev/dri, rootless) reports Radeon 8060S Graphics (RADV
GFX1151) / driver radv / API 1.4.318 with two heaps: heap 0 host-visible 38.67 GiB
(budget 32.58) and heap 1 DEVICE_LOCAL 77.33 GiB (budget 65.16) with frank-dragoon
loaded. ggml's Vulkan backend asks for DEVICE_LOCAL, so the ~4 GiB the TTS engine
needs lands in the 65 GiB budget: memory is not the constraint, and the 2 GiB DRM
carve-out never enters the picture. Both heaps are GTT — the same host RAM, so the
budget is a ceiling on mappings, not free silicon memory.
Traps recorded: vulkaninfo --batch is not a flag in Ubuntu 24.04's vulkan-tools
(prints help, exits 1; use --text), and the container has no NVIDIA ICD, so Vulkan
device 0 happens to be the iGPU — select by name, not index.
Probe: /home/dank/spikes/npu-tts/vk_probe.sh on Dankclaw. Enumeration only; no
allocation, no compute, production untouched.
The trial's quadlet line said AddDevice=/dev/dri/renderD128. Resolved the nodes by
driver instead of assuming: on this hybrid host renderD128 -> nvidia and
renderD129 -> amdgpu, so the guess pointed the engine at the wrong card. Also
records the gate-1 command that works (vulkaninfo --text; --batch prints help and
exits 1) and the probe script path.
dank
merged commit 9971cb559e into main2026-10-19 14:14:46 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
The overnight spike answered "how can frank-tts run on hardware instead of CPU?" — not on the Strix Halo NPU, and the wall is the loader, not the silicon. Docs only; the fleet is untouched and
frank-tts/frank-tts-enginestill servenarrator1|2|3on CPU.Pages
report/tts-npu-spike-verdict-2026-10-19.mdreport/npu-tts-runtime-landscape-2026-10-19.mdreport/qwen3-tts-payload-portability-2026-10-19.mdserverAppConfigs-docs/Dankclaw/Frank TTS.mdFindings worth a skim
xrt-smi validatePASSES incl.throughput, yet the RyzenAI EP opens/dev/accel/accel0, succeeds at the GEM ioctls, then declines the graph and emits zero log lines on every lever (GENAI_ORT_VERBOSE_LOGGING,set_log_callback,RYZENAI_EP_TRACING). One run loaded; byte-identical runs never reproduced it. No token rate is quoted because none was ever measured.vulkaninfoin the engine's own base image reportsDEVICE_LOCAL= 77.33 GiB (budget 65.16 GiB with frank-dragoon loaded) — Mesa splits the 116 GiB aperture ⅓/⅔ on APUs, so the 2 GiB DRM carve-out never enters the picture. Target shape is co-tenancy withfrank-dragoon; the constraint is host RAM (17 GiB available; GTT pages are system pages) and shader time, not the aperture.vulkaninfo --batchdoesn't exist in Ubuntu 24.04'svulkan-tools(prints help, exits 1 — reads like a driver failure), andrenderD128on this hybrid box is the NVIDIA node — the iGPU isrenderD129, so the quadlet must pass/dev/dri, not a guessed number.<|speech_N|>, ids 151,671–217,206), not the 10,001 an earlier note claimed.Checks
./tests/run.sh450/450 green on each commit. No service restarted, no host state changed. Follow-onfeat/frank-tts-vulkan(ordered by Frank) builds on this.cwd: /home/blank/.omp/wt/wt-20261019-020309-6d1fc1f · session: 01a15366-7601-7175-bb69-c62186c3f8b5