rocm-sys 0.0.1

ROCm system bindings configured by release version
rocm-sys-0.0.1 has been yanked.

rocm-sys

FFI bindings to C for ROCm gated by version. Explicitly checks for correct ROCm versions and function calls are guarnateed to be safe provided their prerequisites defined by AMDs documentation.

Usage

This is a very unsafe and low-level API. For a safer API, use rocm.

let mut count = -1;

unsafe {
    hipGetDeviceCount(&mut count);
}

println!("device count = {count}");
  • This will output device count = -1 or device count = 0 on failure or device count = N where N >= 1 on success
  • All hip* functions return a hipError_t

Dynamic Loading vs Static Linking

The API is the same regardless of whether you use dynamic loading or static linking, but the functionality is different. If building for a generic target, use dynamic loading. If running on the build machine, static linking is faster.

Dynamic Static
Runtime Checks Y N
Portable Across Hardware Y N
Compile-Time Linking N Y

To enable dynamic loading, enable the cargo feature dynamic-loading.

When using static linking, all functions are just extern "C" functions wrapped in extern "Rust" functions with some compile-time ROCm version checks when applicable.

Assumptions

This crate tries to assume as little about the target as possible.

  • If dynamic-loading feature is disabled, the target is assumed to be the build machine
  • The size of a Rust usize should be equal to the size of a C size_t
  • hipGetDeviceProperties and hipChooseDevice are only correct profided hipDeviceProp_tR0600 = hipDeviceProp_t

Try to avoid these. Device properties may get patched in the future.

Contribution

All functions are hand-written (albeit using a macro) and types are auto-generated using bindgen.

Functions must be hand-written because they have version checks which bindgen doesnt make automatically. The API is as close to the C API as possible (template functions make this hard).

This is maintained separately from rocm because functions are all hand-written.