Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
vision-rs
A high-performance computer vision SDK for Rust.
Prerequisites
- OS: Ubuntu. This is the only supported development/build platform.
- Rust: the latest stable toolchain, via rustup:
- CUDA Toolkit 13.3 or later on the host (for the
cudafeature — on by default — and for ahead-of-time kernel compilation via the customteenyccompiler; see below). Check with: - This crate's sibling repos, checked out next to
vision-rs(itsCargo.tomlpatchesteeny-*crates to../teenygrad/...and cross builds auto-mount that workspace root): - Only if you'll cross-compile/deploy to a Jetson Orin Nano (see below):
cross, Docker, theaarch64-unknown-linux-gnurustup target,cargo-teeny, and SSH/rsyncaccess to the device.
Getting started
Installing the toolchain
vision-rs builds against the stable Rust compiler, but GPU kernels (Triton/MLIR) are compiled
— both ahead-of-time (cargo teeny package/aot) and at runtime via JIT — by a separate, custom
compiler fork: teenyc (see teenygrad/teeny). You need that binary on your machine and
TEENYC_PATH (in .env) pointing at it before building/running anything that uses the cuda
feature (on by default).
The supported way to get teenyc is via cargo-teeny,
which installs a prebuilt release from the spinorml CDN — you do not need to clone or build
the teeny compiler fork from source for this.
-
Install
cargo-teeny: -
Install the
teenyctoolchain:This downloads and
rustup toolchain links the compiler asstable-teenyc-x86_64-unknown-linux-gnuunder~/.rustup/toolchains/. Verify it:| -
Point
TEENYC_PATHat it..env.dev(copied to.envin "Getting started" above) already defaults to the right path:Adjust
DATASETS_CACHE_DIR/MODELS_CACHE_DIRin the same file to wherever you want benchmark datasets/models cached, then:Do this in every shell before building/running/testing/benchmarking — the examples and test suite compile kernels via
teenycat runtime and needTEENYC_PATHset.
Building
Host (native)
Cross-compilation for Jetson Orin Nano
vision-rs targets the Jetson Orin Nano (aarch64-unknown-linux-gnu) using
cross via the cargo-teeny plugin.
Additional prerequisites
-
Install cross
-
Add the aarch64 target
-
CUDA aarch64 libraries — the build mounts the host CUDA aarch64 target directory into the cross container so the cross-compiled binary links against the CUDA version actually present on the Jetson Orin Nano's JetPack (independent of the host's own CUDA 13.3 from the prerequisites above, which is only used for AOT-compiling kernels on the host). The default path is:
/usr/local/cuda-12.6/targets/aarch64-linuxIf your target device's JetPack CUDA version differs, pass
--cuda-path <path>on everybuild/packagecommand below.
Build
# Build the library in release mode (default)
# Build all examples
# Build a single example
# Type-check only (faster feedback)
# Lint
# Debug build
# Custom CUDA path (target device's JetPack CUDA version)
Compiled artifacts land in target/aarch64-unknown-linux-gnu/release/.
How it works
cargo teeny build wraps cross build and automatically:
- Resolves the teenygrad workspace root from the
[patch.crates-io]entries inCargo.tomland mounts it into the cross container (required because cross only auto-mounts individual crate directories, not the workspace root that providesCargo.tomlinheritance). - Mounts the host CUDA aarch64 target directory at the path the cross container's Dockerfile expects.
- Uses the custom Docker image defined in
docker/Dockerfile.jetson-orin-nano, which extends the cross base image with clang-12 (required bybindgenfor aarch64 cross-bindings).
Packaging a deployable bundle
cargo teeny package combines cross-compiling the binary/example for the target board with
ahead-of-time-compiling its GPU kernels on the host, into one self-contained directory you can
copy straight to the device — no teenyc, CUDA toolkit, or Rust install needed on the Jetson
itself.
--options capability=sm_87is the Jetson Orin Nano's GPU compute capability (Ampere).ptx-version=82overridesteenyc's otherwise-conservative default PTX ISA floor forsm_87— keep this pinned unless your target device is on a materially different CUDA version.- Use
--bin <name>instead of--example <name>when packaging a binary crate. - This produces:
The binary auto-detectsdist/yolo26-orin/ bin/yolo26 # cross-compiled binary cache/ # AOT-compiled GPU kernels conf/ # provenance marker (target/device/options/commit/build time) data/ # empty — populate with models/datasets separately (see "Running", below)cache/as its sibling directory at runtime (no extra env var needed on the device — seeteeny_compiler::compiler::default_cache_dir()), so it uses the pre-compiled kernels instead of trying to JIT-compile (which would fail: there's noteenycon the Jetson).
Deploying to the Orin
- Uses
rsync -aover SSH; set up key-based auth on the device first, or it'll prompt for a password interactively (stdio is inherited, so that works fine too). - By default, re-running
deployonly copies files that aren't already on the remote (safe to re-run after a partial transfer). Pass--overwriteto force everything to re-sync, e.g. after rebuilding/repackaging with changes. --ssh "ssh -p <port>"if the device uses a non-default SSH port.
Running on the device
data/ was scaffolded empty by package — populate it before running anything that needs a
model/dataset, either by:
- letting the binary download it directly on the device (if it has internet access), e.g.:
- or
rsync-ing pre-downloaded models/datasets from your host's$MODELS_CACHE_DIR/$DATASETS_CACHE_DIR(see.env) intodata/on the device instead.
Then run a smoke test, e.g. the same throughput/latency benchmark used in development:
See CLAUDE.md for the full set of yolo26 subcommands (view, verify, train, validate,
...) and additional benchmarking/profiling workflows.