6a06872f09
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.
40 lines
1.3 KiB
TOML
40 lines
1.3 KiB
TOML
[workspace]
|
|
members = [
|
|
"breadpad-shared",
|
|
"breadpad",
|
|
"breadman",
|
|
"breadpad-test",
|
|
]
|
|
resolver = "2"
|
|
|
|
[workspace.package]
|
|
version = "0.4.1"
|
|
edition = "2021"
|
|
license = "MIT"
|
|
authors = ["Breadway"]
|
|
|
|
[workspace.dependencies]
|
|
anyhow = "1"
|
|
tracing = "0.1"
|
|
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
|
|
serde = { version = "1", features = ["derive"] }
|
|
serde_json = "1"
|
|
uuid = { version = "1", features = ["v4"] }
|
|
chrono = { version = "0.4", features = ["serde"] }
|
|
rrule = "0.12"
|
|
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"
|
|
# 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"
|
|
toml = "0.8"
|
|
dirs = "5"
|
|
regex = "1"
|
|
ureq = { version = "2", features = ["json"] }
|