rust-cuda / cuda-sys Goto Github PK

Rust binding to CUDA APIs

License: Apache License 2.0

Rust 99.75% Shell 0.23% C++ 0.02%

cuda-sys's Introduction

cuda-sys

name	crate.io	docs.rs	CUDA
cuda-driver-sys			10.2
cuda-runtime-sys			10.2

Rust binding to CUDA Driver (libcuda.so) and Runtime (libcudart.so) APIs

This crate does NOT include CUDA itself. You need to install on your own.

CUDA Installation

You should install CUDA from the official installer.
or use nvidia/cuda container
- This container does not add libcuda.so to dynamic link path. You need to add it to your ld path LD_LIBRARY_PATH=/usr/local/cuda/lib64/stubs or using ldconfig.

CUDA_LIBRARY_PATH environment variable

If you use system installer (e.g. apt, yum, pacman, and so on), the install path may be different.
$CUDA_LIBRARY_PATH (e.g. /opt/cuda/lib64) environment value adds paths to the list of library searching.
- $CUDA_LIBRARY_PATH is not required on Windows when CUDA is installed via the official Windows installer.
To verify that cuda-sys can find your CUDA installation, you can check that the CUDA_PATH environment variable has been set.

Q & A

Q. Program does not start (can be compiled) with following error message:

error while loading shared libraries: libcuda.so.1: cannot open shared object file: No such file or directory

A. Driver API (libcuda.so) is sometimes installed in a separate directory. You need to find it, and add to LD_LIBRARY_PATH:

LD_LIBRARY_PATH=/usr/local/cuda/lib64/stubs

License

Dual-licensed to be compatible with the Rust project. Licensed under the Apache License, Version 2.0 or the MIT license, at your option. This file may not be copied, modified, or distributed except according to those terms.

You should check the End User License Agreement, which describes NVIDIA Software License Agreement and CUDA Supplement to Software License Agreement.

cuda-sys's People

Contributors

Stargazers

Watchers

cuda-sys's Issues

vector_types::bindgen_test_layout_(u)long* fails on windows

failures:
    vector_types::bindgen_test_layout_long1
    vector_types::bindgen_test_layout_long2
    vector_types::bindgen_test_layout_long3
    vector_types::bindgen_test_layout_long4
    vector_types::bindgen_test_layout_ulong1
    vector_types::bindgen_test_layout_ulong2
    vector_types::bindgen_test_layout_ulong3
    vector_types::bindgen_test_layout_ulong4

test result: FAILED. 89 passed; 8 failed; 0 ignored; 0 measured; 0 filtered out

failures:

---- vector_types::bindgen_test_layout_long1 stdout ----
thread 'vector_types::bindgen_test_layout_long1' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `8`: Size of: long1', src\vector_types.rs:778:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- vector_types::bindgen_test_layout_long2 stdout ----
thread 'vector_types::bindgen_test_layout_long2' panicked at 'assertion failed: `(left == right)`
  left: `8`,
 right: `16`: Size of: long2', src\vector_types.rs:825:5

---- vector_types::bindgen_test_layout_long3 stdout ----
thread 'vector_types::bindgen_test_layout_long3' panicked at 'assertion failed: `(left == right)`
  left: `12`,
 right: `24`: Size of: long3', src\vector_types.rs:874:5

---- vector_types::bindgen_test_layout_long4 stdout ----
thread 'vector_types::bindgen_test_layout_long4' panicked at 'assertion failed: `(left == right)`
  left: `16`,
 right: `32`: Size of: long4', src\vector_types.rs:945:5

---- vector_types::bindgen_test_layout_ulong1 stdout ----
thread 'vector_types::bindgen_test_layout_ulong1' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `8`: Size of: ulong1', src\vector_types.rs:801:5

---- vector_types::bindgen_test_layout_ulong2 stdout ----
thread 'vector_types::bindgen_test_layout_ulong2' panicked at 'assertion failed: `(left == right)`
  left: `8`,
 right: `16`: Size of: ulong2', src\vector_types.rs:849:5

---- vector_types::bindgen_test_layout_ulong3 stdout ----
thread 'vector_types::bindgen_test_layout_ulong3' panicked at 'assertion failed: `(left == right)`
  left: `12`,
 right: `24`: Size of: ulong3', src\vector_types.rs:909:5

---- vector_types::bindgen_test_layout_ulong4 stdout ----
thread 'vector_types::bindgen_test_layout_ulong4' panicked at 'assertion failed: `(left == right)`
  left: `16`,
 right: `32`: Size of: ulong4', src\vector_types.rs:981:5

Add a license

The cuda-sys repository seems to be missing a LICENSE file, and there is no mention in the README, either. Am I correct to assume that this project is dual-licensed MIT and Apache 2.0?

attempted to zero-initialize type `CUDA_MEMCPY3D_st`, which is invalid

Calling CUDA_MEMCPY3D_st::default() results in the following error on rustc 1.53.0 for cuda-driver-sys 0.3.0:

thread 'node047' panicked at 'attempted to zero-initialize type `CUDA_MEMCPY3D_st`, which is invalid', /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/mem/mod.rs:625:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:50:5
   3: core::mem::zeroed
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/mem/mod.rs:625:9
   4: <cuda_driver_sys::CUDA_MEMCPY3D_st as core::default::Default>::default
<...>

*-sys crate design

FFI crate separation, e.g. cuda-sys, cudart-sys, and cublas-sys has benefit

to separately link to libcuda.so, libcudart.so, libcublas.so
to better support cargo feature gates disccused in #5

How to split?

cuda-sys
- FFI for CUDA Driver API (libcuda.so)
cudart-sys
- FFI for CUDA Runtime API (libcudart.so)
cublas-sys
- FFI for cuBLAS

and so on. (edit: Drop cuFFT)

How to manage?

each *-sys crates are managed as a subdirectory in this repository

cuda-sys/cuda-sys/Cargo.toml
         cudart-sys/Cargo.toml
         cublas-sys/Cargo.toml

Duplicate struct definitions in both cuda-runtime-sys and cuda-driver-sys

Things like CUstream_st and CUcontext_st are defined in both crates meaning that they need to be cast or transmuted when used across crate boundaries.

Would be nice if shared definitions could be in a shared crate or if cuda-runtime-sys could depend on cuda-driver-sys and reuse the definitions there.

Also create bindings for /opt/cuda/include/cublasLt.h?

/opt/cuda/include/cublasLt.h is a new flexible API dedicated to GEneral Matrix-to-matrix Multiply (GEMM) operations.

Maintenance this repository

This crates are not maintained now, and I have no time for managing them. If you are interesting to manage and develop this project, please let me know.

Any suggestions are welcome :)

How do I use cuda streams in "rust" with this tool?

I need an example of invoking a cuda stream through this tool.

cublas-sys already exists

OpenGL interop

I need to access the OpenGL interop functions found in cuda_gl_interop.h. The documentation lists them under the Runtime API so they might fit inside the runtime crate.

It does use a few OpenGL types so a dependency on the gl crate is probably needed as well. I don't know how hard it is to add feature flags for different bindgens so maybe a cuda-gl-interop-sys crate is the better route.

Interop crates/features for D3D could probably be added at the same time in a similar manner.

Dynamic loading

Hello! Do you have plans to add support for dynamic loading cuda library at runtime?
Something like rust-dlopen for example.

With current approach this crate will cause crash if CUDA libraries is not found,
instead of raising error to user (so it will be possible to fallback to cpu/opencl code).

Also, with dynamic loading it will be possible to find CUDA libraries at runtime,
so it won't be necessary to do
export DYLD_LIBRARY_PATH=/usr/local/cuda/lib
in MacOS (and probably LD_LIBRARY_PATH in Linux).

CI for Windows

Azure-Pipeline will be good

cuSOLVER bindings

I am planning on using cublas and I'd like to leverage the lapack-like utilites in cuSOLVER, such as SVD. Having a -sys crate of bindings would be great!

For reference: cuSOLVER docs

CUDA_LIBRARY_PATH on Ubuntu

Some users of RustaCUDA have found that setting CUDA_LIBRARY_PATH isn't sufficient to allow them to build cuda-sys: bheisler/RustaCUDA#15

I ran into a similar problem while setting up my Travis-CI builds for RustaCUDA on an Ubuntu VM which might be related. If I set CUDA_LIBRARY_PATH to /usr/local/cuda-8.0/targets/x86_64-linux/lib, it could find libcublas.so and libcudart.so but not libcuda.so (which is in /usr/local/cuda-8.0/targets/x86_64-linux/lib/stubs for some reason).