Support simultaneous ptx and lib building (multiple builds in a single builder)

[guoqingbao]

The current version does not support multiple builder instances and a build instance cannot be used for another build (as also mentioned in #2 ), I have fixed this by making the builder reusable, e.g., building ptx after lib building.

The tested use case:

fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    println!("cargo:rerun-if-changed=src/attention.cu");
    println!("cargo:rerun-if-changed=src/copy_blocks_kernel.cu");
    println!("cargo:rerun-if-changed=src/reshape_and_cache_kernel.cu");
    println!("cargo:rerun-if-changed=src/rotary_embedding_kernel.cu");
    let builder = bindgen_cuda::Builder::default();
    println!("cargo:info={builder:?}");
    builder.build_lib("libattention.a");

    let bindings = builder.build_ptx().unwrap();
    bindings.write("src/lib.rs").unwrap();

    println!("cargo:rustc-link-lib=attention"); 
}

[guoqingbao]

The current version does not support multiple builder instances and a build instance cannot be used for another build (as also mentioned in #2 ), I have fixed this by making the builder reusable, e.g., building ptx after lib building.

The tested use case:

fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    println!("cargo:rerun-if-changed=src/attention.cu");
    println!("cargo:rerun-if-changed=src/copy_blocks_kernel.cu");
    println!("cargo:rerun-if-changed=src/reshape_and_cache_kernel.cu");
    println!("cargo:rerun-if-changed=src/rotary_embedding_kernel.cu");
    let builder = bindgen_cuda::Builder::default();
    println!("cargo:info={builder:?}");
    builder.build_lib("libattention.a");

    let bindings = builder.build_ptx().unwrap();
    bindings.write("src/lib.rs").unwrap();

    println!("cargo:rustc-link-lib=attention"); 
}

This is a different solution by making the builder reusable instead of using multiple thread pools like #3

[guoqingbao]

@ivarflakstad Hi Ivar, are you able to review this PR? I believe the PR at huggingface/candle#3221 depends on this.

[ivarflakstad]

Suggested change

	version = "0.1.7"
	version = "0.1.5"

We can increment the version in a separate PR when creating a new release.

[ivarflakstad]

Nit: Could create a utility ala get_nvcc_binary and avoid the repetition

[Narsil]

This is horrible. Let users setup their own path. This location is hardcoded to specific linux distributions it has nothing to do here.

If you really want allow environment overrides. It's pretty bad too, but at least it won't be hardcoded.

[guoqingbao]

This is horrible. Let users setup their own path. This location is hardcoded to specific linux distributions it has nothing to do here.

If you really want allow environment overrides. It's pretty bad too, but at least it won't be hardcoded.

This is intended as a fallback to the default nvcc path. At the moment, bindgen_cuda can panic even when nvcc is available in the standard installation location (/usr/local/cuda/bin).
Given that, we either provide a reasonable fallback here, or require every user to manually set and hardcode the path in their own environment. A get_nvcc_binary may needed as suggested by @ivarflakstad

[Narsil]

This has nothing to do here.

[Narsil]

They already exist, remove this.

[guoqingbao]

Sorry, it shouldn't be here because I'm pushing to my own forked repo (forgot this has being pushed for a merge). But these interface are actual demand, we haven't expose compute_cap (initialized on default) to users and sometime they need a specific cuda compute cap to build certain kernels (instead of relying on env or nvidia-smi), e.g., flash attention v2 kernels needs to compiled with sm_90 or below even other kernels compiled with sm_120+. Related issue guoqingbao/vllm.rs#194

[Narsil]

There was kind of points to consume the builder...

Everything already works, instead of making build_lib(&self) you should clone the builder directly (so implementing Clone).