HIP support for CUDA/ROCm cross-compatibility?

[kbarros]

This may well be out of scope, but I couldn't find any prior discussion.

Nvidia lock-in is a problem, but we haven't had much choice in scientific computing; Nvidia has a great software stack, which it optimizes at the assembly level. For example, the fastest OpenCL BLAS libraries still lag significantly behind Nvidia's cuBLAS.

To compete with CUDA, AMD has shifted from OpenCL to its ROCm platform. AMD is also developing a thin "HIP" compatibility layer that compiles to either CUDA or ROCm. AMD's hipBLAS, hipSPARSE, and hipDNN all translate to the cu- or roc- equivalents, depending on hardware target. So, for example, hipBLAS would link to either cuBLAS or rocBLAS.

On the hardware side, AMD's Radeon VII now looks competitive with, e.g. Nvidia's 2080 Ti. In particular, its double precision performance is far better (theoretical 3.5 TFLOPS vs 0.37 TFOPS). TensorFlow (HIP version) benchmarks on AMD also look pretty good at single precision.

I wonder if the RustaCUDA community has given any thought to targeting HIP rather than CUDA directly. Would this be a more-or-less automatic source conversion (replace cuda- with hip- prefixes everywhere)? Could this give easy access to both CUDA/ROCm, without sacrificing performance? Could the Rust language somehow give us an advantage for cross-platform GPGPU support? I would be very interested to hear your thoughts.

[EDIT] Just realized the ROCm is Linux-only for now. This is a bummer. Windows support might be on the way. No ETA on Mac support.

[LutzCle]

FYI, there's also a feature table of supported functions.

[bheisler]

Hey, thanks for the suggestion.

I wasn't aware of HIP until now. That's kind of a neat option, and it's good strategy on AMD's part. However, I think supporting it is out-of-scope for this project. It might make sense to build this at some point in the future, but definitely not now. It's not even possible yet to compile Rust source to ROCm binaries, so the users of such a feature would be limited to only those people who want to write their host code in Rust, are OK with writing their device code in C AND are using HIP to be generic over GPGPU vendors. That is a mighty small niche. Add in that they could instead just write a thin layer of C glue code and call it by FFI and the value of such a feature approaches nil. Limited OS support and the early-days nature of the HIP platform are just more nails in that coffin.

Now, if you could compile Rust source to ROCm binaries, it could be more useful. Something like Accel could perhaps decide which format to compile the source to and then users could enable HIP support to support both formats.

As for your other question - Rust has many advantages over C, but I can't see it having any advantages to GPGPU portability that you wouldn't get with C. If anything, it's the other way around - C is preferentially targeted by GPGPU compiler and library authors thanks to its status as the unofficial lingua franca of programming languages. It would take a huge investment to bring up Rust support for ROCm or anything else like it, while supporting CUDA is comparatively easy - most of the hard work is already done by LLVM contributors and the CUDA library and driver authors at NVIDIA. So no, I don't think it's likely to happen unless Rust GPGPU in general takes off in a big way.

[kbarros]

The Department of Energy announced that Frontier, their forthcoming supercomputer in 2021, will have AMD Radeon Instinct GPUs. This is a $600M contract. It seems there will soon be growing pressure for cross-platform (Nvidia/AMD) programming models in the HPC space.

https://www.hpcwire.com/2019/05/07/cray-amd-exascale-frontier-at-oak-ridge/

[rusch95]

RustaCUDA maps pretty strongly to CUDA, so such a thing would probably fair better built on top of rustacuda or cuda-sys

On Tue, May 7, 2019, 16:44 Kipton Barros notifications@github.com wrote:

The Department of Energy announced that Frontier, their forthcoming supercomputer in 2021, will have AMD Radeon Instinct GPUs. This is a $600M contract. It seems there will soon be growing pressure for cross-platform (Nvidia/AMD) programming models in the HPC space.

https://www.hpcwire.com/2019/05/07/cray-amd-exascale-frontier-at-oak-ridge/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bheisler/RustaCUDA/issues/30#issuecomment-490248283, or mute the thread https://github.com/notifications/unsubscribe-auth/ACSQ2KBB6WKCHVSMCA3X24DPUHS3VANCNFSM4G7CM3LA .

[bheisler]

Agreed. RustaCUDA isn't intended to be a generalized GPGPU interface, it's intended to be a low-level binding to the CUDA libraries. A vendor-portable GPGPU interface would be useful (and could potentially be built on top of RustaCUDA) but that's a different project.