WIP

ROCm · May 23, 2024 · 0274a57 · 0274a57
1 parent 2231969
commit 0274a57
Showing 1 changed file with 23 additions and 20 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -30,35 +30,37 @@ Some guidelines are outlined below:
 ### Add a new HIP API ###
 
 * Add a translation to the hipify-clang tool ; many examples abound.
-    * For stat tracking purposes, place the API into an appropriate stat category ("dev", "mem", "stream", etc).
+  * For stat tracking purposes, place the API into an appropriate stat category ("dev", "mem", "stream", etc).
 * Add a inlined NVIDIA implementation for the function in /hipnv/include/hip/nvidia_detail/nvidia_hip_runtime_api.h in the repository [hipother](https://github.com/ROCm/hipother).
-    * These are typically headers
+  * These are typically headers
 * Add an HIP definition and Doxygen comments for the function in /include/hip/hip_runtime_api.h, in the repository [hip](https://github.com/ROCm/hip).
-    * Source implementation typically go in clr/hipamd/src/hip_*.cpp in the reposotory [clr](https://github.com/ROCm/clr). The implementation involves calls to HIP runtime (ie for hipStream_t).
+  * Source implementation typically go in clr/hipamd/src/hip_*.cpp in the reposotory [clr](https://github.com/ROCm/clr). The implementation involves calls to HIP runtime (ie for hipStream_t).
 
 ### Run Unit Tests ###
 
 For new features or bug fixes, it's mandatory to run associate [hip-tests](https://github.com/ROCm/hip-tests).
 Please go to the repo and follow the steps.
 
 For applications and benchmarks outside the hip-tests environment, developments should use a two-step development flow:
+
 * #1. Compile, link, and install HIP. See {ref}`Building the HIP runtime` notes.
 * #2. Relink the target application to include changes in HIP runtime file.
 
 ## Coding Style ##
+
 * Code Indentation:
-    * Tabs should be expanded to spaces.
-    * Use 4 spaces indentation.
+  * Tabs should be expanded to spaces.
+  * Use 4 spaces indentation.
 * Capitalization and Naming
-    * Prefer camelCase for HIP interfaces and internal symbols.  Note HCC uses _ for separator.
-      This guideline is not yet consistently followed in HIP code * eventual compliance is aspirational.
-    * Member variables should begin with a leading "_".  This allows them to be easily distinguished from other variables or functions.
+  * Prefer camelCase for HIP interfaces and internal symbols.  Note HCC uses _ for separator.
+    This guideline is not yet consistently followed in HIP code * eventual compliance is aspirational.
+  * Member variables should begin with a leading "_".  This allows them to be easily distinguished from other variables or functions.
 
 * `{}` placement
-    * namespace should be on same line as `{` and separated by a space.
-    * Single-line if statement should still use `{/}` pair (even though C++ does not require).
-    * For functions, the opening `{` should be placed on a new line.
-    * For if/else blocks, the opening `{` is placed on same line as the if/else. Use a space to separate `{` from if/else. For example,
+  * namespace should be on same line as `{` and separated by a space.
+  * Single-line if statement should still use `{/}` pair (even though C++ does not require).
+  * For functions, the opening `{` should be placed on a new line.
+  * For if/else blocks, the opening `{` is placed on same line as the if/else. Use a space to separate `{` from if/else. For example,
 ```console
     if (foo) {
         doFoo()
@@ -68,10 +70,10 @@ For applications and benchmarks outside the hip-tests environment, developments
 ```
 
 * Miscellaneous
-    * All references in function parameter lists should be const.
-    * "ihip" means internal hip structures.  These should not be exposed through the HIP API.
-    * Keyword TODO refers to a note that should be addressed in long-term.  Could be style issue, software architecture, or known bugs.
-    * FIXME refers to a short-term bug that needs to be addressed.
+  * All references in function parameter lists should be const.
+  * "ihip" means internal hip structures.  These should not be exposed through the HIP API.
+  * Keyword TODO refers to a note that should be addressed in long-term.  Could be style issue, software architecture, or known bugs.
+  * FIXME refers to a short-term bug that needs to be addressed.
 
 * `HIP_INIT_API()` should be placed at the start of each top-level HIP API.  This function will make sure the HIP runtime is initialized, and also constructs an appropriate API string for tracing and CodeXL marker tracing. The arguments to HIP_INIT_API should match those of the parent function.
 * `hipExtGetLastError()` can be called as the AMD platform specific API, to return error code from last HIP API called from the active host thread. `hipGetLastError()` and `hipPeekAtLastError()` can also return the last error that was returned by any of the HIP runtime calls in the same host thread.
@@ -91,10 +93,11 @@ Some tips:
     https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
 
 In particular :
-   * Use imperative voice, ie "Fix this bug", "Refactor the XYZ routine", "Update the doc".
-     Not : "Fixing the bug", "Fixed the bug", "Bug fix", etc.
-   * Subject should summarize the commit.  Do not end subject with a period.  Use a blank line
-     after the subject.
+
+* Use imperative voice, ie "Fix this bug", "Refactor the XYZ routine", "Update the doc".
+  Not : "Fixing the bug", "Fixed the bug", "Bug fix", etc.
+* Subject should summarize the commit.  Do not end subject with a period.  Use a blank line
+  after the subject.
 
 ### Deliverables ###