Files
Lumotia/docs/issues/runtime-capabilities-accelerators.md
Jake 54d9adf1f0 fix(rb-07): runtime capabilities derive accelerators honestly
get_runtime_capabilities was returning `accelerators = ["cpu",
"vulkan"]` and `whisper.supports_gpu = true` regardless of build
config or runtime state. On a macOS build it falsely advertised
"vulkan" (the backend actually resolves via MoltenVK as Metal); on a
whisper-disabled build it claimed GPU support for an engine that
hadn't been linked.

Added `compose_accelerators(whisper_enabled, loader_available, target)`
— a pure helper that always emits "cpu" first and appends the
platform-appropriate GPU name only when whisper is compiled in AND the
Vulkan loader resolves. `supported_accelerators()` wraps it with the
live `cfg!(feature = "whisper")`, loader probe, and target OS.

`get_runtime_capabilities` now calls `supported_accelerators()` and
sets `whisper.supports_gpu = cfg!(feature = "whisper")`. Parakeet
stays CPU-only.

Five tests in `commands::models::tests` cover the permutation matrix:
whisper on/off, loader present/missing, macOS vs other. Both feature
configurations (`--features whisper` and `--no-default-features`)
build and pass tests.

Macos Metal-loader resolution on real hardware stays on the
ship-gate checklist — the detection logic is verifiable from Linux
but runtime behaviour is not.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-22 10:32:04 +01:00

2.8 KiB

RB-07 MAJOR: get_runtime_capabilities advertises wrong accelerators

Severity: MAJOR Path: src-tauri/src/commands/models.rs:435-489 Source: 2026-04-22 code review Labels: release-blocker, major, ui-integrity Status: RESOLVED (2026-04-22)

Resolution

Added a pure compose_accelerators(whisper_enabled, loader_available, target) -> Vec<String> helper. It always emits "cpu" first and appends "metal" (macOS) or "vulkan" (Linux/Windows) only when whisper is compiled in and vulkan_loader_available() resolves the platform's loader shim.

supported_accelerators() reads cfg!(feature = "whisper"), runs the live loader probe, and delegates to the helper. get_runtime_capabilities calls supported_accelerators() in place of the hard-coded vec!["cpu", "vulkan"]. Whisper's supports_gpu is now cfg!(feature = "whisper") — false on whisper-disabled builds.

Five regression tests in commands::models::tests cover:

  • cpu_only_when_whisper_disabled (both targets)
  • cpu_only_when_loader_missing (both targets)
  • macos_with_loader_advertises_metal
  • non_macos_with_loader_advertises_vulkan
  • cpu_is_always_first_entry (contract the frontend relies on)

Both cargo test -p kon --lib and cargo test -p kon --lib --no-default-features pass the new suite; both cargo build -p kon and cargo build -p kon --no-default-features compile clean.

Runtime GUI verification on a real macOS box is still on the ship-gate checklist — the detection logic is correct in code; Metal-loader resolution on hardware is not something we can unit-test from a Linux CI.

Problem

The IPC response hard-codes accelerators = ["cpu", "vulkan"] and supports_gpu = true for Whisper, even when:

  • detect_active_compute_device would report metal on macOS (via MoltenVK).
  • The binary was compiled without the whisper feature — in which case Whisper supports_gpu is meaningless because there is no Whisper backend at all.

The frontend uses this response to render Settings toggles (GPU selection, active-device badge, feature availability). Wrong values mean wrong UI states on exactly the builds this function is meant to describe.

Acceptance

  • accelerators is derived from actual build configuration and runtime probe, not hard-coded.
  • On macOS, accelerators includes "metal" when the Metal loader resolves.
  • On whisper-disabled builds, Whisper entries advertise supports_gpu = false (or the engine is omitted from the response entirely).
  • Regression tests cover each platform variant via cfg-gated test cases.

Fix scope

Medium. The detection helpers already exist (detect_active_compute_device, vulkan_loader_available); this is about wiring their output into the RuntimeCapabilities struct honestly.

Dependencies

  • None — standalone fix.