Assessment of the difficulty in porting CPU architecture for HIP

[wangyuliu]

Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, it can be estimated on average across various architectures.As part of my dataset, I have collected the HIP project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be simple, with a small amount of code related to the CPU architecture in the project. (referring to the overall workload from adapting the project to a specific architecture to achieving full functionality on that architecture). Is this assessment accurate? I look forward to your help and response.

[yxsamliu]

HIP runtime depends on https://github.com/ROCm-Developer-Tools/clr, which in turn depends on https://github.com/RadeonOpenCompute/ROCR-Runtime, which in turn depends on https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver . Probably those dependencies need more effort for porting.

[cjatin]

https://github.com/ROCm-Developer-Tools/HIP-CPU might be worth looking at

[wangyuliu]

I'm very grateful for this and look forward to your further guidance.Can you have a more detailed or specific assessment? For example, our tool believes that there is very little architecture-related code in HIP. We think the porting work is very simple. Do you agree?

[wangyuliu]

https://github.com/ROCm-Developer-Tools/HIP-CPU might be worth looking at

HIP-CPU mentioned--It is generic and does not assume a particular CPU vendor or architecture---, I would like to continue to ask for your opinion, when building the HIP-CPU project, whether a lot of work was done on cpu architecture portability, or whether it took very little effort to make it possible Ignore the difference in CPU architecture?