5 Commits

Include renames

Author	SHA1	Message	Date
dtourolleandClaude Opus 5	39a22875b1	Add the MIGraphX rung for AMD GPUs ... Measured on a Radeon RX 7900 XT against Arch's onnxruntime-rocm 1.29 (docs/inference.md §1.3): MIGraphX fp16 runs the detectors at 2.4–3.4 ms against 10–58 ms on the CPU provider, the inpainter at 8 ms against 514, with a 15–135 s compile per graph the first time and under a second from its cache after. A compiling rung on TensorRT's terms, wired the same way. The ROCm execution provider is gone (removed in ONNX Runtime 1.23), so the AMD ladder is MIGraphX then the CPU, with no non-compiling rung between. MIGraphX is registered through the runtime's generic key/value entry point rather than ort's builder: 1.29 reads the legacy options struct for its precision flags only, and the compiled-program cache directory (`migraphx_model_cache_dir`) only travels the generic way. The provider's cache key omits the precision, so f32 and fp16 programs get their own directories. The probe fingerprint now includes the provider libraries beside the runtime and the ROCm version, since a distribution's CPU and ROCm builds are the same file at the same path. `status().failed` reports only the rungs above the selection, so an AMD desktop's About line says why MIGraphX won rather than that the NVIDIA providers are not in the build. Two examples: `ep_probe` times each provider cold and from cache, and `ladder` drives `init` as the app does to watch the first-run sequence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-20 19:23:00 +02:00
dtourolle	cbbe67fbd7	Let the probe's clock be its proof, not disable_cpu_ep_fallback ... The strict flag refused the Hexagon over the ten quantise/dequantise nodes at the graph's edges that QNN declines by policy, which cost microseconds. A provider that hands real work to the CPU is slower than the CPU floor and the timing already rejects it; the tablet measured 2.3 ms on the NPU against a 29.7 ms floor.	2026-09-19 16:13:19 +02:00
dtourolle	76bc5652d7	Calibrate the int8 detectors on library proxies, in chunks, and measure them ... The first int8 files found no faces at all, and for two reasons the tool now guards against. The calibration set was landscape photographs with no faces in them, so the score head's ranges had never seen the face regime; the set is now proxies from the library itself. And ONNX Runtime's strided and moving-average calibration modes both degrade these graphs measurably (a quarter of the faces at eight images, none at ninety-six), while driving the calibrator in chunks by hand gives ranges identical to a single pass — so the tool does that, four images at a time, and feeds quantize_static through its range cache. Measured against f32 over 400 proxies (docs/inference.md §10.1): the 10g form finds every face above 32 px the f32 form finds; 500m and 2.5g find 96%, and what they lose sits at a median confidence of 0.52 against the 0.50 threshold. Shipped with the number on record. The Android unpack list gains the three int8 files; without that the tablet never saw them. D13's runtime half records the reopening.	2026-09-19 16:02:44 +02:00
dtourolle	caf21bea64	Name the crate dr-inference-engine	2026-09-19 16:02:37 +02:00
dtourolle	6739fdf908	Specify per-device inference backends, with the 2026-09-19 measurements ... tract runs every model on one core on every platform. Measured against ONNX Runtime's providers on the MagicPad 2 and the reference desktop: ORT CPU alone is 3-10x, the Hexagon at int8 runs the detectors in 1-3 ms, TensorRT is ~2x the CUDA provider. NNAPI, XNNPACK, WebGPU and CUDA int8 were tried and excluded with the numbers that excluded them. The spec keeps the build C-free: ort::set_api takes a table from a dlopened runtime or from ort-tract, chosen once per process. Rungs are chosen by building a real session, cached until an input changes, and compiled engines are built in the background after the first frame. The embedder stays f32 everywhere; int8 detectors are a distinct model_id and are gated on a recall measurement.	2026-09-19 16:02:37 +02:00