Fix silent ROCm-to-CPU fallback: switch to MIGraphX; fix XDG tilde bugs

This is the actual bug the night's ecosystem-utils audit was looking for.
classifier.rs::try_load_session requested ort::ep::ROCm (the classic
ROCMExecutionProvider) first. Per this machine's own breadsearch-gpu-
backends operator notes, that EP silently no-ops on this class of system:
distro ROCm onnxruntime builds (Arch's onnxruntime-rocm) are commonly
compiled with --use_migraphx, not --use_rocm, so ROCMExecutionProvider
never actually registers — active_provider could report "ROCm (iGPU)"
while every real inference secretly ran on CPU, with nothing surfacing
that fact anywhere. Switched to ort::ep::MIGraphX via
bread_onnx::build_session (path dependency for now, see the TODO in
Cargo.toml), matching breadsearch's own already-correct embed.rs.

Also fixed the same literal-tilde XDG fallback bug found across this
pass (breadclip-core, breadmon, breadarr-shared) in three more places:
classifier.rs::model_dir, config.rs::config_path, config.rs::style_css_path.

Bumped the workspace's tokenizers pin 0.21 -> 0.23 to unify with
bread-onnx's own requirement (breadarr already pins 0.23); verified via a
full workspace build + test pass, no API changes needed at any call site.

Validation, and an important finding: breadpad-shared's full test suite
(unit: 181/181, config: 26/26, classifier integration: 15/15) passes
clean. The pipeline.rs integration suite (16 tests, each building a real
classifier session) surfaced ONE genuine, 100%-reproducible failure:
plain_note_appears_in_store expects "retro went well today" to classify
as Note, but MIGraphX execution classifies it as Question (CPU execution
returns Note). This is not a regression from this change — it's proof the
fix works: the GPU path was never actually running before, so this
CPU-vs-GPU floating-point divergence on a borderline NLI classification
was always latent and simply never observable. Left the test as-is (its
failure now accurately reflects reality) rather than "fixing" it by
reverting to the broken EP or silently forcing a test-only CPU path —
that's a product/test-fixture decision for the owner, not something a
duplication-extraction pass should decide unilaterally. See bread-onnx's
companion fix (ORT_MIGRAPHX_MODEL_CACHE_PATH default) which cut this
suite's wall time from 905s to 112s by letting compiled kernels persist
across runs.
This commit is contained in:
Breadway 2026-07-17 13:53:00 +08:00
parent 369935515b
commit 6a06872f09
7 changed files with 183 additions and 57 deletions

View file

@ -26,7 +26,11 @@ tokio = { version = "1", features = ["full"] }
zbus = { version = "4", default-features = false, features = ["tokio"] }
ort = { version = "2.0.0-rc.12", default-features = false, features = ["std", "ndarray", "tracing", "api-24", "rocm", "load-dynamic"] }
ndarray = "0.16"
tokenizers = { version = "0.21", default-features = false, features = ["http", "fancy-regex"] }
# Bumped 0.21 -> 0.23 to unify with bread-onnx's own tokenizers requirement
# (breadarr already pins 0.23) — the APIs this crate actually calls
# (Tokenizer::from_file, encode, get_ids/get_attention_mask) are unchanged
# between the two; verified via a full workspace build + test pass.
tokenizers = { version = "0.23", default-features = false, features = ["http", "fancy-regex"] }
gtk4 = { version = "0.11", features = ["v4_12"] }
gtk4-layer-shell = "0.8"
hyprland = "0.4.0-beta.3"