Runtime dependencies

Native runtimes are resolved by DENKflow automatically. Every ONNX execution provider uses DENKflow's built-in, pinned managed ONNX Runtime 1.22.1 under <data dir>/dependencies/onnxruntime/. Barcode reading requires a barcode reader backend, Ambarella models require the runtime that exactly matches the exported model and target chip, and accelerated ONNX providers may also require CUDA, TensorRT, DirectML, or OpenVINO libraries. Managed files are stored under <data dir>/dependencies/ and tracked in a local manifest.db.

<data dir> is the SDK data directory (see Configuration and DENKFLOW_DATA_DIRECTORY).

Online (default)

The first time a pipeline needs a dependency, the SDK uses the pipeline's Hub credentials to download the required files, verifies each one, and records it in the manifest. A CPU-only pipeline needs the managed ONNX Runtime just as an accelerated pipeline does. Subsequent runs reuse the verified local copy without downloading it again.

A confirmation prompt is shown before downloading when stdin is a terminal. When stdin is not a terminal (CI, containers, piped input), downloads and license terms are auto-confirmed. Set DENKFLOW_NONINTERACTIVE=1 to force the same auto-confirm behavior when in an interactive terminal.

Ambarella runtime files are stored in a chip-specific directory such as dependencies/ambarella/cv22/ or dependencies/ambarella/n1-655/. Do not copy files between these directories: the SDK validates the chip and runtime version before initializing the model. See Ambarella deployment for supported chips and device prerequisites.

CUDA, TensorRT, DirectML, and OpenVINO

Pipelines that select the CUDA, TensorRT, DirectML, or OpenVINO execution provider need matching native libraries. Before downloading a managed copy into <data dir>/dependencies/, the SDK checks whether a compatible version is already installed on the system (via common install roots and environment variables such as CUDA_PATH / CUDA_HOME, CUDNN_HOME / CUDNN_PATH, TENSORRT_ROOT, and INTEL_OPENVINO_DIR / OpenVINO_DIR). Standard Linux multiarch library and include directories are searched as well, including /usr/lib/aarch64-linux-gnu and /usr/include/aarch64-linux-gnu on Jetson. If the detected version is compatible, the system install is used and no provider-runtime download is performed. This system lookup does not apply to ONNX Runtime itself: version 1.22.1 is always managed under dependencies/onnxruntime/.

A system CUDA install is accepted only when both the CUDA toolkit (12.0–12.9) and cuDNN 9.x are present. Managed CUDA archives bundle the matching cuDNN libraries in the same tree. The release-pinned managed fallback is CUDA 12.6 on Linux AArch64 and CUDA 12.8 on other supported platforms.

TensorRT resolution also requires a compatible CUDA stack (system or managed). On Linux AArch64, the SDK prefers JetPack's system TensorRT when its version is between 10.0 and 10.9 inclusive; if no compatible system install is detected, the managed fallback is TensorRT 10.3. Other platforms accept the system TensorRT 10.9 line and use the managed 10.9 package as fallback.

OpenVINO system resolution accepts the 2025.1 line. If no compatible system runtime is found, the SDK uses its managed OpenVINO dependency.

On Windows, DirectML resolution checks an app-local DirectML.dll and the inbox copy under the Windows system directory. ONNX Runtime 1.22.1 requires DirectML 1.15.4 or newer. If the discovered DLL is missing, unreadable, or older, the SDK downloads DirectML 1.15.4 into dependencies/directml/ and preloads that managed copy before creating the inference session.

If a system install looks compatible by version but fails at session creation, force the managed dependency tree with DENKFLOW_FORCE_MANAGED_DEPS:

export DENKFLOW_FORCE_MANAGED_DEPS=1

For local testing with hand-placed libraries under dependencies/cuda/ (or tensorrt/ / directml/ / openvino/), you can use DENKFLOW_USE_EXISTING_DEPS:

export DENKFLOW_USE_EXISTING_DEPS=1

This skips installation, archive import, repair, and verification. The SDK uses an existing managed subdirectory without checking its version or hashes, then falls back to a compatible system installation. If neither exists, dependency resolution continues without installing a runtime, so session creation may fail later.

Managed packages live under dependencies/onnxruntime/, dependencies/cuda/, dependencies/tensorrt/, dependencies/directml/, and dependencies/openvino/.

Offline (manual)

When the machine has no hub access, provide the dependency manually:

1. On a machine with internet access, download the matching .denkdependency archives from the Hub under Software -> DENKflow Dependencies. Every ONNX pipeline needs the ONNX Runtime 1.22.1 archive; also download each provider or feature runtime the pipeline requires.
2. Copy the file directly into either <data dir>/dependencies/ or the dependency import directory. The import directory defaults to the process working directory and can be changed with DENKFLOW_DEPENDENCY_IMPORT_DIRECTORY.

On the next run the SDK discovers the archive before any network call, verifies its contents against the embedded manifest, and extracts and records the files. The archive remains in its source directory after import, allowing it to be reused; remove it manually when it is no longer needed.

For Ambarella, choose the archive for the exact chip and runtime version shown by the initialization error. Users of compiled packages do not need the Ambarella SDK or DENKflow source code to import an offline dependency.

Advanced ONNX Runtime override

The SDK configures ORT_DYLIB_PATH internally after resolving its managed ONNX Runtime. Users normally should not set it. The variable remains available only for advanced testing with an intentionally supplied ONNX Runtime build, which may be incompatible with the release-pinned provider runtimes.