Repository navigation
Add a Windows GPU Whisper build via whisper.cpp Vulkan - #179
Merged
Merged
Conversation
Add a Windows + Vulkan branch to the whisper.cpp engine's build.rs — generic GPU across AMD/Intel/NVIDIA with ggml's CPU fallback — gated behind a new `vulkan` feature so the default Windows build stays a no-op shell and needs no Vulkan SDK. Widen the crate's cfg to compile on Windows under that feature. This is the lighter Windows GPU path: whisper.cpp + Vulkan builds in minutes, unlike sherpa-onnx DirectML (no upstream prebuilt; compiles onnxruntime from source for hours). A windows-vulkan smoke workflow installs the Vulkan SDK and validates the from-source build links.
`cargo -p pkg --features vulkan` errors with "cannot specify features for packages outside of workspace" from the workspace root; use the package- qualified `pkg/vulkan` form.
wisp-engine-whisper-cpp is excluded from the root workspace (with the other native crates), so `cargo -p … --features` rejects it as "outside of workspace". Build it standalone via --manifest-path, and point the diagnostic lib scan at the crate's own target dir.
find_package(Vulkan) failed on the runner even with VULKAN_SDK set. Pin the SDK to a known-good version (1.4.309.0) and pass Vulkan_INCLUDE_DIR + Vulkan_LIBRARY to CMake explicitly so it doesn't rely on auto-detection.
ggml-vulkan appends the SDK to CMAKE_PREFIX_PATH only when VULKAN_SDK is in the cmake environment, which cmake-rs does not forward. Pass it through (and set CMAKE_PREFIX_PATH) so find_package(SPIRV-Headers / SPIRV-Tools) succeeds.
The Vulkan SDK ships SPIRV-HeadersConfig.cmake flat in Lib/cmake rather than in a SPIRV-Headers/ subdir, so find_package needs that directory on the prefix path directly, not just the SDK root.
ggml-vulkan builds its vulkan-shaders-gen host tool via ExternalProject, which
fails under the Visual Studio generator ("No CMAKE_C_COMPILER could be found").
Switch the Windows build to Ninja and set up the MSVC dev environment so every
sub-build finds cl.exe.
The vulkan-shaders-gen sub-build nests so deeply that its .pdb path exceeds
260 chars ("cannot open program database"). Point CARGO_TARGET_DIR at a short
root so every nested path stays under the limit.
Add a `whisper-vulkan` app feature (enables wisp-engine-whisper-cpp/vulkan), make the crate a Windows dependency, and widen build_whisper_cpp_engine's cfg to compile on Windows under that feature. The default Windows build and macOS are unchanged. The smoke workflow now builds the whole app (sherpa CPU + whisper Vulkan) to validate it compiles and links end to end.
family_runnable now allows the whisper.cpp family on Windows when the `whisper-vulkan` feature is built (the app propagates it to wisp-models), so the picker offers Whisper on the GPU build — running on Vulkan, or CPU via the backend's fallback. The default Windows build and macOS are unchanged.
Replace the cargo-build smoke with a full `tauri build --features whisper-vulkan`, so the run produces the real NSIS installer (sherpa on CPU, whisper on the Vulkan GPU) and proves the bundler honours CARGO_TARGET_DIR=D:\b before that recipe is wired into release.yml. Upload the installer as an artifact so it can be tested on real Windows hardware (GPU and non-GPU).
The upload listed two paths on different drives (the D:\b bundle dir and a workspace-relative fallback), so upload-artifact computed a common-ancestor root under D:\a that didn't contain the actual file on D:\b. The build and NSIS bundle already succeed and land the installer at D:\b\release\bundle\nsis — point the upload at that single absolute path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
whisper-vulkanfeature — a generic GPU path (AMD, Intel, NVIDIA) with whisper.cpp's built-in CPU fallback. macOS keeps its Metal + CoreML build; the default Windows build (sherpa on CPU) is unchanged.family_runnableis now platform- and feature-aware, so the picker surfaces Whisper there instead of greying it out as macOS/Metal-only.windows-vulkan.yml) that builds the engine and the full NSIS installer, and uploads the installer as an artifact for on-hardware testing.Unlike the sherpa-onnx DirectML path (compiles onnxruntime from source for hours, no upstream prebuilt), whisper.cpp + Vulkan links in minutes and covers any Vulkan GPU.
Test plan
--features whisper-vulkan(sherpa CPU + whisper Vulkan coexist) — run 27108397827tauri buildproduces the NSIS installer (artifactwisp-windows-gpu-installer) — run 27108627289Notes
release.ymlis unchanged: the shipped Windows installer stays the CPU build until the GPU installer is verified on real hardware. Wiring the proven recipe (MSVC env + Vulkan SDK 1.4.309.0 + Ninja +CARGO_TARGET_DIR=D:\b+--features whisper-vulkan) into the Windows release job is a follow-up.