Remove the copy of HIP header(s).

[dfukalov]

At the moment Triton uses the partially copied header(s) triton/include/triton/external/hip.h from HIP/ROCm. It seems it would be better to #include <hip/hip_runtime_api.h> (points to /opt/rocm/hip/hip_runtime_api.h).

But Triton should be able to build without installed ROCm so I see two main approaches to implement the functionality:

1. Guard all use places of HIP API things with #if defined(USE_ROCM) but I'm not sure it will be possible without pain
2. Use a stub header (created from the current triton/include/triton/external/hip.h) in case Triton is built without ROCm support. E.g.:

#if defined(USE_ROCM)
#include <hip/hip_runtime_api.h>`
#else
#include "hip_stub.h"
#endif

@ptillet @micmelesse what do you think?

[ptillet]

Hey! As you may know, we are rewriting the backend, and will temporarily drop references to the AMD runtime there. It will be readded when codegen for AMD hardware also happens (it's not in the short term plans for now).

In the meantime, i think it's wise to keep it in the main repo for future reference. Also, runtimes in Triton are handled by dynamically loading shared objects, so #ifdefs shouldn't be necessary.

[dfukalov]

Thanks for reply,
We are actually trying to update the rocm branch to support ROCm 5.x. But such updates may conflict with concrete copy of HIP API in Triton's hip.h.

But if Trtion starts to include header from installed ROCm, build on CUDA systems will be broken since there are a lot of places where HIP related stuff (types, methods etc) are compiled unconditionally.
I had another look to sources and it seems there will be a lot of work to use HIP headers from ROCm and keep Triton buildable on CUDA systems without ROCm...

I guess at the moment it will be better to just update copied HIP API to a newer version of ROCm,

[ptillet]

Oh I see! Yeah then feel free to modify hip things as needed and submit a PR :)