embed.rs's OrtEmbedder now delegates its tokenize -> tensor build ->
mean-pool -> L2-normalize pipeline to bread_onnx::embedding::EmbeddingSession
(near-byte-identical to breadarrd's own OrtEmbedder — same duplication, now
shared, path dependency for now, see the TODO in breadmill/Cargo.toml), and
its per-EP session builders (npu_session/rocm_session/cuda_session/
openvino_session) collapse into a single to_provider() mapping onto
bread_onnx::Provider, which this crate's own breadmill/src/session.rs
counterpart now handles generically. This crate's Backend enum, cargo
feature gates (npu/rocm/cuda/openvino/full - unchanged, still control which
onnxruntime EPs actually link/load), and NPU vaip_config.json discovery all
stay local since they're genuinely breadsearch-specific. main.rs's Backend
construction and CLI flag handling are untouched.
This is also the reference implementation the MIGraphX-not-ROCm default in
bread-onnx's provider module was promoted from (see this machine's own
breadsearch-gpu-backends operator notes) — breadpad's ONNX migration, which
had the actual silent-fallback bug, follows in a later commit.
download_if_missing is replaced with bread_onnx::download::ensure_file
(same sync/ureq approach, now shared with breadarrd's downloader).
Builds clean with default features AND --features full (npu+rocm+cuda+
openvino all compiling together, matching how this crate already combined
them). All existing tests pass across the whole workspace.
- indexer.rs: embedder mutex is now locked only around each chunk's
embed_document() call instead of the whole file's chunk loop, so a slow
MIGraphX JIT compile on one file no longer blocks every query for minutes
- sync_ext.rs (new)/indexer.rs/main.rs/serve.rs: added MutexExt::lock_recover(),
replacing every .lock().unwrap() so a panic on one thread (poisoning the
mutex) logs a warning and recovers instead of cascading into every future
lock().unwrap() call
- store.rs: save_index now writes to a .tmp sibling and renames atomically
into place; Store::open recovers from an index that fails to load by
wiping it and the SQLite files/chunks tables so the next scan rebuilds
from scratch, instead of refusing to start at all. Note: this recovery
only catches corruption usearch's loader reports as Err — verified
experimentally that sufficiently garbled input segfaults the process
instead, which no Rust-side handling can catch; the atomic save is what
actually prevents the realistic mid-crash corruption case from arising
- breadsearch/src/main.rs: GUI query-result wait switched from
glib::idle_add_local (re-invoked every main-loop tick, pegging a core for
the whole wait) to a 15ms glib::timeout_add_local poll
- breadsearch/Cargo.toml: bread-theme pin bumped v0.2.8 -> v0.2.10 to match
the rest of the family
The model load ran synchronously on the main thread before serve::run()
bound the daemon's socket. A slow or stuck EP compile (OpenVINO in
particular) meant the socket didn't exist for as long as that took, so
every client -- including the breadsearch GUI -- saw a bare connection
refused with no way to tell "still loading" from "actually broken."
The load now happens on a background thread; the socket binds
immediately, and serve.rs's existing model_ready check answers
"model not ready" for any request that arrives before the load finishes.
Mirrors the rocm/cuda pattern: ort::ep::OpenVINO with device_type "GPU"
(covers both Intel integrated graphics and Arc discrete GPUs through the
same EP), load-dynamic/dlopen so no OpenVINO toolkit is needed at build
time, and its own --openvino flag / backend = "openvino" config value.
Folded into the `full` feature alongside npu/rocm/cuda.
OpenVINO's provider options go through a generic key/value FFI interface
rather than a fixed C struct (unlike MIGraphX's OrtMIGraphXProviderOptions),
so it should be less exposed to the ABI-version-skew crash MIGraphX hit --
but that's inference from the EP's design, not verified against real
hardware. Like CUDA, this is compile-checked only: no Intel GPU in this
dev environment to runtime-verify against.
Version bump: breadmill 0.2.2 -> 0.2.3.
Without a valid MIGraphX cache dir, ONNX Runtime's MIGraphX EP reads an
uninitialized cache path and crashes on the first query rather than just
recompiling on every restart -- confirmed by hand while verifying the rocm
backend. Previously commented out as an opt-in perf tweak; it's actually
required for the rocm backend to work at all, so bakery-installed systems
need it set by default. No-op for cpu/npu/cuda backends.
Version bump: breadmill 0.2.1 -> 0.2.2.
Adds breadmill's `full` feature (npu + rocm + cuda together) and switches
the release workflow to build with it. All three backends are ort's
load-dynamic (dlopen) mode, so combining them doesn't require the NPU/ROCm/
CUDA toolkits on the build host -- which backend is actually available is
resolved at runtime via ORT_DYLIB_PATH / the dynamic linker, per whichever
backend is selected for that run.
Also fixes a real bug this surfaced: backend selection checked
`config.model.backend == "rocm"` unconditionally in an if/else-if chain, so
an explicit --cuda (or --npu) flag silently lost to an unrelated `backend`
value already sitting in config.toml. CLI flags now always take priority
over config.
Version bump: breadmill 0.2.0 -> 0.2.1.
ROCm silently fell back to CPU: the code targeted ONNX Runtime's classic
ROCMExecutionProvider, but distro ROCm-enabled ONNX Runtime builds (e.g.
Arch's onnxruntime-rocm) are commonly compiled with --use_migraphx instead,
and registration failures were invisible since breadmill never installed a
tracing subscriber. Switches the rocm feature to target MIGraphX, adds a
default tracing subscriber so EP registration success/failure is always
visible, and fixes a real crash where MIGraphX's output sequence padding
could index the attention mask out of bounds during mean-pooling.
Also adds a CUDA backend (--cuda / backend = "cuda") mirroring the same
ort execution-provider pattern, for NVIDIA hardware.
Version bump: 0.1.0 -> 0.2.0.
GitHub Actions self-hosted runners need per-repo registration on a
personal account; Forgejo Actions' runner already serves every repo
with zero setup. Moves release publishing there (dl.breadway.dev stays
the primary bakery target; GitHub release upload is kept as the
fallback via an explicit token, since Forgejo Actions has no ambient
GITHUB_TOKEN) and adds a mirror workflow to keep GitHub in sync
automatically.
