Provide hipify to convert CUDA code to ROCm/HIP for AMD GPUs

[EmmanuelMess]

Running on less expensive AMD GPUs might be somewhat easy to implement, with hipify, either automatically converting the code or doing a manual run of hipify.

Is your feature request related to a problem? Please describe.
Cannot run on AMD GPUs as is.

Describe the solution you'd like
Hipify code conversion.

Describe alternatives you've considered
Converting to CPU with Eigen and optimizing on CPU?

Additional context
I have an AMD GPU.

[woensug-choi]

@EmmanuelMess Hi! I would love to this further about this matter. I have been thinking about similar idea for quite some time now. I've never heard of the hipify, but I was thinking about utilizing WebGPU but have not dived in to it much yet. If there is any possible way to commonly usable method as WebGPU, wouldn't it be better than using CUDA or Hipify?

[EmmanuelMess]

I've never heard of the hipify, but I was thinking about utilizing WebGPU but have not dived in to it much yet.

Isn't WebGPU only for browsers?

If you are looking for generic GPU computing I would recommend OpenCL, but there could be a performance hit due to lack of hardware specific optimizations, also you'd have to maintain two codebases if you want to keep both OpenCL and CUDA. With hipify, you can add a compilation step to convert the CUDA to ROCm/HIP.

[woensug-choi]

@EmmanuelMess Sorry, the WebGPU is for browsers, I meant, the wgpu which is usable outisde browsers.

WebGPU = the standard
wgpu = a native implementation of that standard

[EmmanuelMess]

@EmmanuelMess Sorry, the WebGPU is for browsers, I meant, the wgpu which is usable outisde browsers.

WebGPU = the standard wgpu = a native implementation of that standard

wgpu seems to be an API for rust, that makes use of graphics oriented GPU interfaces (Vulkan, Metal, DirectX 12, OpenGL ES) but not GPGPU interfaces (CUDA, HIP, OpenCL) which is what you need in this project.

[woensug-choi]

@arjo129 I am bit confused here! wgpu is for GPGPU right?

[arjo129]

Yes, WGPU is a native implementation of WebGPU that runs perfectly well outside of a browser. It supports compute shaders natively and compiles to the appropriate target backend (Vulkan, Metal, DX12) behind the scenes. If the project is primarily C++, there are mature bindings available.

Regarding the comparison to GPGPU-specific APIs:

• Optimization: While it might not reach the peak "to-the-metal" optimization of CUDA or HIP for highly specific kernels, it is more than sufficient for DAVE’s current sonar pipeline.

• Portability: Since the project already uses CUDA, "Hipify" might seem like a path of least resistance for AMD, but that doesn't solve the problem for Intel or Apple Silicon users. In an ideal world, our GPU-related code should not be tied to specific vendors, just as we expect our CPU-based software to be portable.

For DAVE's specific use case, WGPU is likely the better long-term choice. The current sonar implementation involves a rasterization pass followed by an FFT-based computation. Modern graphics cards (even lower-end ones) handle this beautifully via standard compute shaders. We don't need specialized GPGPU features like bfloats or tensor cores for this; we need broad accessibility.

One of the biggest wins here would be native support for macOS. Newer Apple Silicon hardware is incredibly capable, and enabling DAVE to run natively on a Mac would significantly lower the barrier for many researchers and developers.

For reference I have had great success writing a hardware accelerated RT LiDAR in WGPU for Gazebo.

[EmmanuelMess]

I think you would still be using a graphics API for GPGPU, which can be done (for some computations), but might encounter issues. If you need a generic API I would recommend OpenCL, which is oriented to the general computation usecase and should run on anything with a GPU.

[arjo129]

Opencl is a good choice as well. It is worth noting it is deprecated but does work on macos. It might be worth benchmarking and comparing the two.