HIP
HIP copied to clipboard
ROCm
Porting HIP to run on other (non-AMD) accelerators
Hello,
If I were to have a novel accelerator, I would need to have a programming model for users to interact with it. From my understanding, AMD wants HIP to be a defacto programming model for the community wit-large to use, and potentially for other vendors to use as a means for interacting with their accelerator.
If I were to have a novel accelerator, how viable is it to port HIP to run on it? Is HIP intended to be an AMD-only thing, or is it really intended to be open for others to use with their accelerator? If it's open for all, are there any developer guides or documentation on how one should go about porting HIP to run on a new accelerator?
I understand OpenCL exists, but HIP has much wider adoption in the HPC and AI communities than OpenCL does. For example, all of the ECP applications for Frontier use HIP (or SYCL). Also, Pytorch and Tensorflow support HIP but not OpenCL directly. Those are some of reasons why HIP is more attractive for us than OpenCL.
Sorry if this is the wrong venue for this question; is there a better forum for these kinds of questions?
HIP assumes a SIMT programming model and requires the accelerator work to be expressible as a series of series of launches of up-to 3D arrays of threads/work-items, much like Cuda, and OpenCL. Does this make sense for your accelerator?
We'd definitely want to do those types of computations on this accelerator. It sounds like you're saying "yes, you can port HIP to run on another accelerator, but it makes some assumptions around the accelerator using SIMT". Is that accurate? If so, are there any guides or documentations on how to port HIP to run on another accelerator?
Also, I thought HIP worked for AMD CPU-only solutions as well. From your response about SIMT, maybe that's not the case. If one had a cluster that had just AMD cpus, HIP wouldn't work?
It is possible to port HIP to other platforms. Actually, there is already a HIP port on the non-AMD device:
https://github.com/CHIP-SPV/chipStar
This project is an implementation of HIP on top of OpenCL or Level0. There are three critical components for HIP:
The compiler: HIP uses clang/llvm as compiler. If your device also uses clang/llvm as compiler, it is pretty straightforward to let clang support your device for HIP since the front end is primarily target neutral. Another approach is letting clang emit SPIRV as CHIP-SPV does since they have a compiler that can compile SPIRV to their ISA.
The device library: HIP device APIs are implemented on top of functions in the device library.
HIP runtime: HIP host APIs are implemented on top of rocCLR, which is implemented on top of ROCm runtime. If your device already supports OpenCL, then HIP host APIs can be implemented on top of OpenCL runtime as CHIP-SPV does.
Also, I thought HIP worked for AMD CPU-only solutions as well. From your response about SIMT, maybe that's not the case. If one had a cluster that had just AMD cpus, HIP wouldn't work?
There is HIP on CPU but it is a separate project https://github.com/ROCm-Developer-Tools/HIP-CPU
Thanks for the good pointers, all. This definitely looks promising.
Another question I had is around upstreaming. Ideally, we'd want to be able to upstream changes or additions we make. We don't want to have to maintain a separate port. Does HIP allow upstreaming of changes to work on other accelerators? I see the other projects listed here are forks.
For the compiler, you can upstream your changes to support HIP with your target by the regular Phabricator review process of LLVM/Clang. I can help review your changes as I did for the HIPSPV toolchain.
I will leave the question to Brian and the HIP runtime team about the device library and HIP runtime.
Regarding the device libraries, they are AMD specific and assume an AMD runtime. We will not accept changes adding support for other devices or platforms. However they can be, and have been, adapted for other uses as permitted by the license. Also, ports of HIP to other platforms have been able to port HIP device-side runtime calls onto their own device libraries.
This is more clear to me now, thank you. We do have an API that sits on top of our architecture, so it might just be having the lower layers of HIP make calls into this API.
Also, I see here that ROCm can run ontop of OpenMP target/offload:
https://docs.amd.com/en/docs-5.3.0/reference/openmp/openmp.html
Since, according to this (https://www.admin-magazine.com/var/ezflow_site/storage/images/media/images/amd-discover_f03/167845-2-eng-US/AMD-Discover_F03_reference.jpg), HIP sits ontop of ROCm. Wouldn't it be possible then to have HIP just use OpenMP target/offload via ROCm?
Sorry for so many questions, but thank you very much for the fast replies.
