Update HIP docs

Purge all obsoleted information that is only relevant to HCC Change-Id: Ice6ae174a73ccac9dfe2ca05027d1ecdb32558d7
2020-10-16 16:31:51 -04:00
@@ -49,18 +49,18 @@ Rather than present two separate APIs, HIP extends the HIP API with new APIs for
 ### hipModule API

 Like the CUDA Driver API, the Module API provides additional control over how code is loaded, including options to load code from files or from in-memory pointers.
-NVCC and HCC target different architectures and use different code object formats: NVCC is `cubin` or `ptx` files, while the HCC path is the `hsaco` format.
+NVCC and HIP-Clang target different architectures and use different code object formats: NVCC is `cubin` or `ptx` files, while the HIP-Clang path is the `hsaco` format.
 The external compilers which generate these code objects are responsible for generating and loading the correct code object for each platform.
-Notably, there is not a fat binary format that can contain code for both NVCC and HCC platforms. The following table summarizes the formats used on each platform:
+Notably, there is not a fat binary format that can contain code for both NVCC and HIP-Clang platforms. The following table summarizes the formats used on each platform:

-| Format        | APIs                             | NVCC               | HCC               | HIP-CLANG    |
-| ---           | ---                              | ---                | ---               | ---
-| Code Object   | hipModuleLoad, hipModuleLoadData | .cubin or PTX text | .hsaco            | .hsaco       |
-| Fat Binary    | hipModuleLoadFatBin              | .fatbin            | Under Development | .hip_fatbin  |
+| Format        | APIs                             | NVCC               | HIP-CLANG    |
+| ---           | ---                              | ---                | ---          |
+| Code Object   | hipModuleLoad, hipModuleLoadData | .cubin or PTX text | .hsaco       |
+| Fat Binary    | hipModuleLoadFatBin              | .fatbin            | .hip_fatbin  |

-`hipcc` uses NVCC and HCC to compile host codes. Both of these may embed code objects into the final executable, and these code objects will be automatically loaded when the application starts.
+`hipcc` uses HIP-Clang or NVCC to compile host codes. Both of these may embed code objects into the final executable, and these code objects will be automatically loaded when the application starts.
 The hipModule API can be used to load additional code objects, and in this way provides an extended capability to the automatically loaded code objects.
-HCC allows both of these capabilities to be used together, if desired. Of course it is possible to create a program with no kernels and thus no automatic loading.
+HIP-Clang allows both of these capabilities to be used together, if desired. Of course it is possible to create a program with no kernels and thus no automatic loading.


 ### hipCtx API
@@ -77,22 +77,16 @@ The first flavor may be faster in some cases since they avoid host overhead to d

 HIP defines a single error space, and uses camel-case for all errors (i.e. `hipErrorInvalidValue`).

-### HCC Implementation Notes
-#### .hsaco
-The .hsaco format used by HCC is described in more detail [here](https://github.com/RadeonOpenCompute/ROCm-ComputeABI-Doc).
-An example and blog that show how to use the format is [here](http://gpuopen.com/rocm-with-harmony-combining-opencl-hcc-hsa-in-a-single-program). hsaco can be generated by hcc + extractkernel tool, cloc, the GCN assembler, or other tools.
-
 #### Address Spaces
-HCC defines a process-wide address space where the CPU and all devices allocate addresses from a single unified pool.
+HIP-Clang defines a process-wide address space where the CPU and all devices allocate addresses from a single unified pool.
 Thus addresses may be shared between contexts, and unlike the original CUDA definition a new context does not create a new address space for the device.

 #### Using hipModuleLaunchKernel
-`hipModuleLaunchKernel` is `cuLaunchKernel` in HIP world. It takes the same arguments as `cuLaunchKernel`. The argument `kernelParams` is not fully implemented for HCC. The workaround for it is, to use platform specific macros for each target. Or, `extra` argument can be used which works on both the platforms.
+`hipModuleLaunchKernel` is `cuLaunchKernel` in HIP world. It takes the same arguments as `cuLaunchKernel`.

 #### Additional Information
- HCC allocates staging buffers (used for unpinned copies) on a per-device basis.
- HCC creates a primary context when the HIP API is called. So in a pure driver API code, HIP/HCC will create a primary context while HIP/NVCC will have empty context stack.
-HIP/HCC will push primary context to context stack when it is empty. This can have subtle differences on applications which mix the runtime and driver APIs.
+- HIP-Clang creates a primary context when the HIP API is called. So in a pure driver API code, HIP-Clang will create a primary context while HIP/NVCC will have empty context stack.
+HIP-Clang will push primary context to context stack when it is empty. This can have subtle differences on applications which mix the runtime and driver APIs.

 ### hip-clang Implementation Notes
 #### .hip_fatbin
@@ -130,9 +124,9 @@ CUDA applications may want to mix CUDA driver code with HIP code (see example be

 #### Compilation Options
 The `hipModule_t` interface does not support `cuModuleLoadDataEx` function, which is used to control PTX compilation options.
-HCC does not use PTX and does not support these compilation options.
-In fact, HCC code objects always contain fully compiled ISA and do not require additional compilation as a part of the load step.
-The corresponding HIP function `hipModuleLoadDataEx` behaves as `hipModuleLoadData` on HCC path (compilation options are not used) and as `cuModuleLoadDataEx` on NVCC path.
+HIP-Clang does not use PTX and does not support these compilation options.
+In fact, HIP-Clang code objects always contain fully compiled ISA and do not require additional compilation as a part of the load step.
+The corresponding HIP function `hipModuleLoadDataEx` behaves as `hipModuleLoadData` on HIP-Clang path (compilation options are not used) and as `cuModuleLoadDataEx` on NVCC path.
 For example (CUDA):
 ```
 CUmodule module;
@@ -164,7 +158,7 @@ options[0] = hipJitOptionMaxRegisters;
 unsigned maxRegs = 15;
 optionValues[0] = (void*)(&maxRegs);

-// hipModuleLoadData(module, imagePtr) will be called on HCC path, JIT options will not be used, and
+// hipModuleLoadData(module, imagePtr) will be called on HIP-Clang path, JIT options will not be used, and
 // cupModuleLoadDataEx(module, imagePtr, numOptions, options, optionValues) will be called on NVCC path
 hipModuleLoadDataEx(module, imagePtr, numOptions, options, optionValues);