HIP VS AMDGPU.jl

>ROCm or HIP?

I'm not sure that's even the right question to ask. Afaik ROCm is the name of that entire tech stack and HIP is AMD's equivalent to CUDA C++ (they basically replicated the API and replaced every "CUDA" by "hip", they have functions called "hipmalloc" and "hipmemcpy").

The repository is located at https://github.com/ROCm/HIP.

Is it perhaps because they want people to use HIP?

> HIP is very thin and has little or no performance impact over coding directly in CUDA mode.

> The HIPIFY tools automatically convert source from CUDA to HIP.

1. https://github.com/ROCm/HIP

AMD has released HIP and a tool called HIPIFY which kind of behaves like this but at the source level¹. Rather than try and just translate CUDA to work on AMD compute they are more focused on higher level tooling.

Currently they seem to have a particular focus on AI frameworks and tools like PyTorch/Tensorflow/ONNX. They have sponsored and helped with a lot of PyTorch development for example, so PyTorch support for AMD is much better than it was this time last year².

¹(https://github.com/ROCm/HIP)

²(https://pytorch.org/blog/experience-power-pytorch-2.0/)

> what would be the point for someone to add ROCm support to various pieces of software which currently require CUDA

It isn't just old cards though, CUDA is a point of centralization on a single provider during a time when access to that providers higher end cards isn't even available and that is causing people to look elsewhere.

ROCm supports CUDA through the included HIP projects...

https://github.com/ROCm/HIP

https://github.com/ROCm/HIPCC

https://github.com/ROCm/HIPIFY

The later will regex replace your CUDA methods with HIP methods. If it is as easy as running hipify on your codebase (or just coding to HIP apis), it certainly makes sense to do so.

AMD's equivalent is HIP [1], for sufficiently flexible definitions of "equivalent". I can't speak to how complete/correct/performant it is (I'm just a guy running tutorial/toy-level ML stuff on an RDNA1 card), but part of AMD's problem is that it might not practically matter how well they do this because the broader ecosystem support specifically for the CUDA stack is so entrenched.

[1] https://github.com/ROCm-Developer-Tools/HIP

From what I know, modern GPUs are still programmed with C++ exclusively. See CUDA [0] for Nvidia and ROCm [1] for AMD.

Why is this? Why Rust is not loved there?

[0] https://docs.nvidia.com/cuda/

[1] https://github.com/ROCm-Developer-Tools/HIP

Go ahead and try to ship ROCm code that works on multiple consumer graphics cards on Linux, MacOS, and Windows. As an example of how much AMD cares about it, the installation notes linked to in the readme returns a 404.

For myself, I use Julia to write my own software (that is run on AMD supercomputer) on Fedora system, using 6800XT. For my experience, everything worked nicely. To install you need to install rocm-opencl package with dnf, AMD Julia package (AMDGPU.jl), add yourself to video group and you are good to go. Also, Julia's KernelAbstractions.jl is a good to have, when writing portable code.

The Julia package AMDGPU.jl provides a Julia interface for AMD GPU (ROCm) programming. As they say, the package is being developed for Julia 1.7, 1.9 and above, but not 1.8. Therefore I downloaded the Julia binary of version 1.7.3 from the older releases Julia page.

This is exciting news! What's also exciting is that it's not just C++ that can run on this supercomputer; there is also good (currently unofficial) support for programming those GPUs from Julia, via the AMDGPU.jl library (note: I am the author/maintainer of this library). Some of our users have been able to run AMDGPU.jl's testsuite on the Crusher test system (which is an attached testing system with the same hardware configuration as Frontier), as well as their own domain-specific programs that use AMDGPU.jl.

What's nice about programming GPUs in Julia is that you can write code once and execute it on multiple kinds of GPUs, with excellent performance. The KernelAbstractions.jl library makes this possible for compute kernels by acting as a frontend to AMDGPU.jl, CUDA.jl, and soon Metal.jl and oneAPI.jl, allowing a single piece of code to be portable to AMD, NVIDIA, Intel, and Apple GPUs, and also CPUs. Similarly, the GPUArrays.jl library allows the same behavior for idiomatic array operations, and will automatically dispatch calls to BLAS, FFT, RNG, linear solver, and DNN vendor-provided libraries when appropriate.

I'm personally looking forward to helping researchers get their Julia code up and running on Frontier so that we can push scientific computing to the max!

Library link: <https://github.com/JuliaGPU/AMDGPU.jl>

GitHub - JuliaGPU/AMDGPU.jl: AMD GPU (ROCm) programming in Julia

https://github.com/JuliaGPU/AMDGPU.jl

https://github.com/JuliaGPU/oneAPI.jl

These are both less mature than CUDA.jl, but are in active development.