Use of Cuda terminology instead of HIP terminology in coordinate built-ins about hip-cpu HOT 3 CLOSED

Thank you for creating this, however I am afraid that it merely points out that HIP's documentation is out of date. The macros are / should be deprecated and never used in current code, where the natural (CUDA, if you want) indexing syntax is preferred. This is / should be guidance for HIP in general, as the macros are way past their expiry date. They were never "native" HIP terminology, but rather a workaround we tried to love because we didn't (at the time) know how to do the other syntax well (fortunately, we learned). I suggest it might be nice to create an issue against HIP itself asking for the documentation to be updated.

from hip-cpu.

Thanks for the fast answer. I understand your point, but I don't agree with the wontfix status.
The README file in the current repository says:

The HIP CPU Runtime is a header-only library that allows CPUs to execute unmodified HIP code.

My reading of this statement is HIP-CPU has no role of law enforcement of the HIP code syntax but rather to be as close as possible to HIP-GPU's behaviour.

An existing HIP code using the above mentioned "hipXXX" acronyms currently compiles without any deprecation message and runs on any AMD GPU, even with the most recent version of ROCm, while it does not currently compile with HIP-CPU without being modified.

The corresponding #define statements are still present in the HIP-GPU source code for the same legacy reasons I guess.
https://github.com/ROCm-Developer-Tools/HIP/blob/main/include/hip/hcc_detail/hip_runtime.h.

Wouldn't it be worth adding the following lines at end of include/hip/hip_runtime.h?

#define hipThreadIdx_x threadIdx.x
#define hipThreadIdx_y threadIdx.y
#define hipThreadIdx_z threadIdx.z

#define hipBlockIdx_x blockIdx.x
#define hipBlockIdx_y blockIdx.y
#define hipBlockIdx_z blockIdx.z

#define hipBlockDim_x blockDim.x
#define hipBlockDim_y blockDim.y
#define hipBlockDim_z blockDim.z

#define hipGridDim_x gridDim.x
#define hipGridDim_y gridDim.y
#define hipGridDim_z gridDim.z

It's up to you to decide.

from hip-cpu.

Your viewpoint is appreciated and your feedback is acknowledged. However, whilst the disagreement is noted, in this case we have considered the matter and chose not to encourage anti-patterns, therefore this'll not be added anytime soon. I would be surprised if an actual HIP de jure HIP specification will legislate said macros. If that expectation were to be proven wrong, this is definitely worth re-visiting. Until then, we'll try to adhere to commonly accepted good practices and try not to squat on the global namespace with macros unless we absolutely cannot avoid it, which is not the case here.

from hip-cpu.