Repository navigation
Desktop 06.10 batch with Windows on ARM (ATO-252) - #614
Merged
Merged
Conversation
On a Windows PC with an RTX 3080 Ti the managed llama-server could not load its CUDA build and ran on the CPU. llama-server.log said "no usable GPU found" from its first lines; the app said nothing and the person watched "Working..." for three and a half minutes before going back to the cloud. Main now reads the end of llama-server.log at each start the app makes or finds (daemon-watch, on the lifecycle "started"), counting only the lines after the last "[atomic-agent] launch:" line, so a warning from an earlier run never speaks for this one. A CPU build picked on purpose (localModels.managed.backendVariant "cpu") is left out. The finding goes to agent.log and Diagnostics at WARN, and to the window on the existing app:daemonWatch channel as a cpu_only notice (also in daemonWatchState for a window opened later), which never touches the supervisor's incident. The window says it once per start: one line on the app line, and a strip above the composer while the route is the local model, with "Use a cloud model" (the existing switch to the cloud) and a dismiss that holds until the next start. Smoke 113: the pure detector over a log with two starts (CPU then GPU: no; GPU then CPU: yes; no launch line: no; backendVariant cpu: no), and the strip drawn once on the local route, never on the cloud route.
… (ATO-244) The cuda-13.3 Windows zip of turboquant-6df272c ships ggml-cuda.dll without cudart64_13 / cublas64_13 / cublasLt64_13. On a machine without the CUDA Toolkit the CUDA backend fails to load silently, llama-server lists no devices and the model runs on the CPU. Detection sent every driver reporting CUDA >= 13.0 (r580+) there. Selection: a driver with CUDA >= 12.4 now gets the cuda-12.4 build, which bundles its runtime and has native code for Ampere, Ada and Hopper. Blackwell (compute capability >= 10, RTX 50-series), which the 12.4 toolkit has no code for, gets Vulkan. The capability comes from `nvidia-smi --query-gpu=compute_cap`; a failed query counts as pre-Blackwell. cuda-13.3 stays available as a pin. Guard: a Windows CUDA install with ggml-cuda.dll but no cudart64_*.dll is stale for the variant check (auto-detection only, pins are left alone), and the installer refuses such a zip, installing the release's Vulkan build and recording the refusal so the next start does not pull the same broken zip again. Existing cuda-13.3 installs are replaced on the next managed start through the existing auto-update variant check. (cherry picked from commit c28487e)
desktop/scripts/smoke-ci.mjs starts the in-repo smoke (electron . --smoke) from plain node on any platform, with an isolated home, temp, state dir, workspace and Chromium profile, the way the QA kit's smoke.sh does without bash. It fails only on FAIL lines not in a known-failures file, or when the run never finishes, and collects the agent's logs for upload. .github/workflows/desktop-smoke-windows.yml builds the agent bundle and the desktop like desktop.yml's Windows job (no signing, no installer) and runs it on windows-latest, on dispatch and on PRs into rel/xp-build.
Checks whose harness runs a /bin/sh stand-in (T11, T18 U*, T30/T31, T41, most of T44). A first draft from the code, to be trimmed after a real run.
… every release-fix task by default, list more stand-in failures
…50); hand the window its ground after the theme has painted (ATO-251)
- bundle targets and the matrix printer know win32-arm64 (windows-11-arm). - ripgrep is pinned per target: 14.1.1 has no aarch64-pc-windows-msvc build, so win32-arm64 alone takes 15.1.0; the tested targets stay on 14.1.1. - afterPack accepts win32-arm64. - electron-builder's nsis target no longer pins x64: the CLI arch flag decides, one arch per job, and the file name carries the arch. - desktop.yml gets a win32-arm64 row on windows-11-arm with an arm64 Node, every Windows step runs for both slugs, bundle/ripgrep paths follow the slug, and the signature check reads win-arm64-unpacked on arm64. Signing keeps the x64 smctl/KSP/signtool (emulated on ARM); first run there, unverified.
…eed (ATO-252) electron-updater on Windows reads one stable.yml for every arch and picks the installer whose name carries process.arch. Each Windows job writes its own, so scripts/merge-update-yml.mjs joins them before upload: both installers in files[], the legacy path/sha512 kept on x64, the later releaseDate. The README's feed section says so.
…when none is published (ATO-252) - win32-arm64 resolves to llama-turboquant-windows-arm64-cpu.zip (llama-server.exe, same build/bin layout as x64) instead of throwing. - resolveDownloadAsset keeps that one asset on arm64: no nvidia-smi probe, backendVariant ignored. The CPU-backend fallback never runs there. - With no release carrying the arm64 zip, downloadBackend and `models update` (nothing installed) say "Local models are not available yet for Windows on ARM. Use a cloud model instead."; the desktop's setup download shows that line instead of "exited with code 1". - The desktop does not warn "running on the CPU" on Windows on ARM, where the CPU build is the only one.
True when an x64 build runs translated on ARM hardware (Windows on ARM emulation, Rosetta), where arch says x64. Counts the ARM machines still on the x64 build.
…64 (ATO-252) On windows-11-arm everything up to signing works, then the x64 signtool with DigiCert's x64 KSP hangs forever under emulation on `signtool sign` (run 37470241594; the same step takes 5 s on win32-x64). DigiCert ships smctl and the KSP for x64 only, so signing cannot happen on that runner. - The win32-arm64 matrix row is gone; the x64, mac and linux rows are unchanged. - agent-win32-arm64 (windows-11-arm, arm64 Node): npm ci, build, SEA, ripgrep, package-bundle, a PE machine check that the agent, ripgrep and better-sqlite3 are arm64, `--version` and the afterPack `task list` database probe on the staged bundle, then uploads bundle/win32-arm64 unsigned. It signs nothing. - package-win32-arm64 (windows-2022, needs the above): downloads the bundle, signs its three binaries in place with the same DigiCert steps as win32-x64, `electron-builder --win --arm64` with the same signing hook, verifies signatures in win-arm64-unpacked, checks the installer's signer CN, uploads desktop-win32-arm64. The feed/signing gate runs in both jobs. - after-pack.mjs: the probe skip for win32-arm64 packed on win32-x64 now says where the probe ran; any other host/target mismatch fails in CI instead of skipping (a local cross-pack still skips).
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.
The desktop 06.10 batch (#612) plus Windows on ARM (ATO-252). It supersedes #612.
Windows ARM64:
windows-11-arm, checked to be ARM64, smoke-tested (--versionand atask listdatabase probe), then signed and packed intoAtomic-Agent-Setup-<v>-arm64.exeon x64. The x64 DigiCert signtool hangs under emulation on the ARM runner.desktop/scripts/merge-update-yml.mjsmerges the x64 and arm64stable.ymlinto the one file electron-updater reads on Windows.llama-turboquant-windows-arm64-cpu.zip(engine releaseturboquant-9ca222f) and ignoresbackendVariant. When no release carries that asset, it says plainly that local models are not available yet on Windows on ARM.arm64_translationproperty counts ARM users still on the x64 build.windows-11-arm.The core part (
src/local-llm,src/cli) also goes to main separately.