rdambrosio

5 ms·

1.
by rdambrosio 5y ago
> there’s no speed to be gained by using this relative to CUDA. That is not totally true, there are two main things that can make kernels generated by this codegen faster: - noalias, which is the LLVM equivalent of __restrict__, CUDA can
2.
by rdambrosio 5y ago
There is one issue i dont know how to solve, its generic kernels. It's a bit impossible to do without doing some seriously weird handling of it in rustc. I can monomorphize ahead of time but monomorphization from the CPU that talks fro
3.
by rdambrosio 5y ago
Not for the near future, HIP does not seem to be language-agnostic and the codegen is for NVVM IR, not whatever AMD uses. It might be possible to target amdgpu with llvm because all the gpu-unfriendly things are gone in my codegen. So maybe
4.
by rdambrosio 5y ago
That is basically what im going to do. It will break down approximately like this: pub fn get_shared_mem_ptr<const Bytes: usize>() -> \*mut u8 { __nvvm_get_shared_mem_ptr(Bytes) } For the raw version, the codegen inter
5.
by rdambrosio 5y ago
> Cuda-rust will probably add (probably does already) some sort of inline assembly Already done and used a lot in cuda_std, it uses normal asm!. My idea for shared memory is that it will always be unsafe and the only thing i can do is: -
6.
by rdambrosio 5y ago
Accel uses the LLVM PTX backend, which is unusable for serious projects and doesn't work on windows, i have more about it here https://github.com/RDambrosio016/Rust-CUDA/blob/master/guide...
7.
by rdambrosio 5y ago
As i mentioned, it is an early project, just making the simplest kernel compile was very difficult. Atomics and shared memory are great, but both are very difficult. Atomics need "proper" atomics (i.e. special instructions on sm_