AI/rocm-systems
2
0
Форкнуть 0
Код Задачи Запросы на слияние Действия Пакеты Проекты Релизы Вики Активность

SWDEV-451170 - Merge PR#3432 to amd-staging

Просмотр исходного кода 
Change-Id: I210bced4e626fc2ac464b80172132481b882cf63
Этот коммит содержится в:
Julia Jiang
2024-03-18 15:48:19 -04:00
коммит произвёл Julia Jiang
родитель c0d0504d2d
Коммит fee13d6a3f
43 изменённых файлов: 16767 добавлений и 1859 удалений
Скачать Patch файл Скачать Diff файл Показать все файлы Свернуть все файлы
.readthedocs.yaml
+4
Просмотреть файл
@@ -19,3 +19,7 @@ build:
apt_packages:
- "doxygen"
- "graphviz" # For dot graphs in doxygen
jobs:
post_checkout:
- git clone --depth=1 --single-branch --branch rocdoc-195 https://github.com/StreamHPC/llvm-project.git ../llvm-project
- git clone --depth=1 --single-branch --branch develop https://github.com/ROCm/clr.git ../clr
docs/developer_guide/contributing.md → docs/about/contributing.md
+9 -6
Просмотреть файл
@@ -1,7 +1,11 @@
# Contributor Guidelines
# Contributor guidelines
## Make Tips
`ROCM_PATH` is path where ROCM is installed. BY default `ROCM_PATH` is `/opt/rocm`.
If you want to contribute to the HIP project, review the following guidelines. If you want to contribute
to our documentation, refer to {doc}`Contribute to ROCm docs <rocm:contribute/contributing>`.
## Make tips
`ROCM_PATH` is path where ROCm is installed. BY default `ROCM_PATH` is `/opt/rocm`.
When building HIP, you will likely want to build and install to a local user-accessible directory (rather than `<ROCM_PATH>`).
This can be easily be done by setting the `-DCMAKE_INSTALL_PREFIX` variable when running cmake. Typical use case is to
set `CMAKE_INSTALL_PREFIX` to your HIP git root, and then ensure `HIP_PATH` points to this directory. For example
@@ -15,9 +19,8 @@ export HIP_PATH=
After making HIP, don't forget the "make install" step !
## Add a new HIP API
## Adding 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).
- Add a inlined NVIDIA implementation for the function in include/hip/nvidia_detail/hip_runtime_api.h.
@@ -68,7 +71,7 @@ To run `hip-tests` please go to the repo and follow the steps.
`hip-tests` provide a great place to develop new features alongside the associated test.
For applications and benchmarks outside the hip-tests environment, developments should use a two-step development flow:
- #1. Compile, link, and install HIP/ROCclr. See [Installation](README.md#Installation) notes.
- #1. Compile, link, and install HIP/ROCclr. See {ref}`Building the HIP runtime` notes.
- #2. Relink the target application to include changes in HIP runtime file.
## Environment Variables
docs/conf.py
+5
Просмотреть файл
@@ -37,3 +37,8 @@ external_projects_current_project = "hip"
for sphinx_var in ROCmDocs.SPHINX_VARS:
globals()[sphinx_var] = getattr(docs_core, sphinx_var)
extensions += ["sphinxcontrib.doxylink"]
cpp_id_attributes = ["__global__", "__device__", "__host__", "__forceinline__", "static"]
cpp_paren_attributes = ["__declspec"]
docs/data/reference/programming_model/memory_hierarchy.drawio
+412
Просмотреть файл
@@ -0,0 +1,412 @@
<mxfile host="65bd71144e">
<diagram id="zBbb_w2fufU70cdOGtND" name="1 oldal">
<mxGraphModel dx="2445" dy="776" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="0" pageScale="1" pageWidth="660" pageHeight="610" background="none" math="0" shadow="0">
<root>
<mxCell id="0"/>
<mxCell id="1" parent="0"/>
<mxCell id="5927" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#5E5B61;fontColor=#FFFFFF;strokeColor=none;spacing=0;" parent="1" vertex="1">
<mxGeometry width="610" height="370" as="geometry"/>
</mxCell>
<mxCell id="5928" value="Grid" style="text;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;rounded=0;fontFamily=klavika;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="275" width="60" height="30" as="geometry"/>
</mxCell>
<mxCell id="5925" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#4F1623;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="10" y="30" width="590" height="280" as="geometry"/>
</mxCell>
<mxCell id="5879" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="310" y="60" width="280" height="240" as="geometry"/>
</mxCell>
<mxCell id="5835" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="20" y="60" width="280" height="240" as="geometry"/>
</mxCell>
<mxCell id="5836" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Block&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="130" y="60" width="60" height="30" as="geometry"/>
</mxCell>
<mxCell id="5837" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#523E43;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="30" y="90" width="260" height="120" as="geometry"/>
</mxCell>
<mxCell id="5838" value="" style="group" parent="1" vertex="1" connectable="0">
<mxGeometry x="40" y="120" width="110" height="80" as="geometry"/>
</mxCell>
<mxCell id="5839" value="&lt;span style=&quot;color: rgba(0, 0, 0, 0); font-family: monospace; font-size: 0px; text-align: start;&quot;&gt;%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%26lt%3Bfont%20face%3D%26quot%3BKlavika%26quot%3B%20style%3D%26quot%3Bfont-size%3A%2017px%3B%26quot%3B%26gt%3BCluster%20shared%26lt%3B%2Ffont%26gt%3B%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D17%3BfontColor%3D%23FFFFFF%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%221007.5%22%20y%3D%22150%22%20width%3D%22115%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#585556;fontColor=#FFFFFF;strokeColor=none;container=0;" parent="5838" vertex="1">
<mxGeometry width="110" height="80" as="geometry"/>
</mxCell>
<mxCell id="5840" value="Warp" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="5838" vertex="1">
<mxGeometry x="18.333333333333332" width="73.33333333333333" height="30" as="geometry"/>
</mxCell>
<mxCell id="5841" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="12.051111111111092" y="26.5" as="sourcePoint"/>
<mxPoint x="12.051111111111092" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5842" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="24.273333333333454" y="26.5" as="sourcePoint"/>
<mxPoint x="24.273333333333454" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5843" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="36.4955555555555" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="36.4955555555555" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5844" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="48.71777777777786" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="48.71777777777786" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5845" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="60.94000000000001" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="60.94000000000001" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5846" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="73.16222222222237" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="73.16222222222237" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5847" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="85.38444444444443" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="85.38444444444443" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5848" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5838" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="97.60666666666678" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="97.60666666666678" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5849" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="6.416666666666666" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5850" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="18.333333333333332" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5851" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="30.25" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5852" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="42.166666666666664" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5853" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="55" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5854" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="66.91666666666666" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5855" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="78.83333333333333" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5856" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5838" vertex="1">
<mxGeometry x="90.75" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5857" value="" style="group" parent="1" vertex="1" connectable="0">
<mxGeometry x="160" y="120" width="120" height="80" as="geometry"/>
</mxCell>
<mxCell id="5858" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#585556;fontColor=#FFFFFF;strokeColor=none;container=0;" parent="5857" vertex="1">
<mxGeometry width="120" height="80" as="geometry"/>
</mxCell>
<mxCell id="5859" value="Warp" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="5857" vertex="1">
<mxGeometry x="20" width="80" height="30" as="geometry"/>
</mxCell>
<mxCell id="5860" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="13.146666666666647" y="26.5" as="sourcePoint"/>
<mxPoint x="13.146666666666647" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5861" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="26.480000000000132" y="26.5" as="sourcePoint"/>
<mxPoint x="26.480000000000132" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5862" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="39.813333333333276" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="39.813333333333276" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5863" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="53.14666666666676" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="53.14666666666676" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5864" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="66.48000000000002" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="66.48000000000002" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5865" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="79.8133333333335" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="79.8133333333335" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5866" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="93.14666666666665" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="93.14666666666665" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5867" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5857" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="106.48000000000013" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="106.48000000000013" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5868" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="7" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5869" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="20" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5870" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="33" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5871" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="46" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5872" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="60" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5873" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="73" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5874" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="86" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5875" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5857" vertex="1">
<mxGeometry x="99" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5878" value="Local" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="1" vertex="1">
<mxGeometry x="120" y="90" width="80" height="30" as="geometry"/>
</mxCell>
<mxCell id="5692" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#4F1623;fontColor=#FFFFFF;strokeColor=none;opacity=75;" parent="1" vertex="1">
<mxGeometry x="30" y="220" width="550" height="70" as="geometry"/>
</mxCell>
<mxCell id="5693" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Cluster shared&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="247.5" y="260" width="115" height="30" as="geometry"/>
</mxCell>
<mxCell id="5876" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#9C2A44;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="40" y="230" width="240" height="30" as="geometry"/>
</mxCell>
<mxCell id="5877" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Shared&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="130" y="230" width="60" height="30" as="geometry"/>
</mxCell>
<mxCell id="5880" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Block&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="420" y="60" width="60" height="30" as="geometry"/>
</mxCell>
<mxCell id="5881" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#523E43;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="320" y="90" width="260" height="120" as="geometry"/>
</mxCell>
<mxCell id="5882" value="" style="group" parent="1" vertex="1" connectable="0">
<mxGeometry x="330" y="120" width="110" height="80" as="geometry"/>
</mxCell>
<mxCell id="5883" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#585556;fontColor=#FFFFFF;strokeColor=none;container=0;" parent="5882" vertex="1">
<mxGeometry width="110" height="80" as="geometry"/>
</mxCell>
<mxCell id="5884" value="Warp" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="5882" vertex="1">
<mxGeometry x="18.333333333333332" width="73.33333333333333" height="30" as="geometry"/>
</mxCell>
<mxCell id="5885" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="12.051111111111092" y="26.5" as="sourcePoint"/>
<mxPoint x="12.051111111111092" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5886" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="24.273333333333454" y="26.5" as="sourcePoint"/>
<mxPoint x="24.273333333333454" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5887" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="36.4955555555555" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="36.4955555555555" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5888" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="48.71777777777786" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="48.71777777777786" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5889" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="60.94000000000001" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="60.94000000000001" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5890" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="73.16222222222237" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="73.16222222222237" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5891" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="85.38444444444443" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="85.38444444444443" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5892" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5882" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="97.60666666666678" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="97.60666666666678" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5893" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="6.416666666666666" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5894" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="18.333333333333332" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5895" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="30.25" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5896" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="42.166666666666664" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5897" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="55" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5898" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="66.91666666666666" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5899" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="78.83333333333333" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5900" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5882" vertex="1">
<mxGeometry x="90.75" y="27" width="4.583333333333333" height="37" as="geometry"/>
</mxCell>
<mxCell id="5901" value="" style="group" parent="1" vertex="1" connectable="0">
<mxGeometry x="450" y="120" width="120" height="80" as="geometry"/>
</mxCell>
<mxCell id="5902" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#585556;fontColor=#FFFFFF;strokeColor=none;container=0;" parent="5901" vertex="1">
<mxGeometry width="120" height="80" as="geometry"/>
</mxCell>
<mxCell id="5903" value="Warp" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="5901" vertex="1">
<mxGeometry x="20" width="80" height="30" as="geometry"/>
</mxCell>
<mxCell id="5904" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="13.146666666666647" y="26.5" as="sourcePoint"/>
<mxPoint x="13.146666666666647" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5905" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="26.480000000000132" y="26.5" as="sourcePoint"/>
<mxPoint x="26.480000000000132" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5906" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="39.813333333333276" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="39.813333333333276" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5907" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="53.14666666666676" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="53.14666666666676" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5908" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="66.48000000000002" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="66.48000000000002" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5909" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="79.8133333333335" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="79.8133333333335" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5910" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="93.14666666666665" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="93.14666666666665" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5911" value="" style="endArrow=classic;html=1;dashed=1;strokeColor=#FFFFFF;fontColor=#FFFFFF;" parent="5901" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="106.48000000000013" y="26.500000000000057" as="sourcePoint"/>
<mxPoint x="106.48000000000013" y="73.5" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5912" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="7" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5913" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="20" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5914" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="33" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5915" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="46" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5916" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="60" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5917" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="73" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5918" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="86" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5919" value="" style="rounded=0;whiteSpace=wrap;html=1;strokeColor=none;fillColor=#523E43;" parent="5901" vertex="1">
<mxGeometry x="99" y="27" width="5" height="37" as="geometry"/>
</mxCell>
<mxCell id="5920" value="Local" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontFamily=Klavika;fontSize=17;fontColor=#FFFFFF;container=0;" parent="1" vertex="1">
<mxGeometry x="410" y="90" width="80" height="30" as="geometry"/>
</mxCell>
<mxCell id="5923" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#9C2A44;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="330" y="230" width="240" height="30" as="geometry"/>
</mxCell>
<mxCell id="5924" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Shared&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="420" y="230" width="60" height="30" as="geometry"/>
</mxCell>
<mxCell id="5926" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Cluster&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="273.75" y="30" width="62.5" height="30" as="geometry"/>
</mxCell>
<mxCell id="5930" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#262626;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="10" y="320" width="590" height="40" as="geometry"/>
</mxCell>
<mxCell id="5940" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Global&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="392.5" y="325" width="115" height="30" as="geometry"/>
</mxCell>
<mxCell id="5941" value="&lt;span style=&quot;color: rgba(0, 0, 0, 0); font-family: monospace; font-size: 0px; text-align: start;&quot;&gt;%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%26lt%3Bfont%20face%3D%26quot%3BKlavika%26quot%3B%20style%3D%26quot%3Bfont-size%3A%2017px%3B%26quot%3B%26gt%3BCluster%20shared%26lt%3B%2Ffont%26gt%3B%22%20style%3D%22text%3Bhtml%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3BwhiteSpace%3Dwrap%3Brounded%3D0%3BfontSize%3D17%3BfontColor%3D%23FFFFFF%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%221007.5%22%20y%3D%22150%22%20width%3D%22115%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E&lt;/span&gt;" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#585556;fontColor=#FFFFFF;strokeColor=none;container=0;" parent="1" vertex="1">
<mxGeometry x="20" y="325" width="90" height="30" as="geometry"/>
</mxCell>
<mxCell id="5942" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Constant&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="30" y="325" width="70" height="30" as="geometry"/>
</mxCell>
<mxCell id="5943" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#9C2A44;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="120" y="325" width="110" height="30" as="geometry"/>
</mxCell>
<mxCell id="5944" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Texture&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="140" y="325" width="70" height="30" as="geometry"/>
</mxCell>
<mxCell id="5945" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#9C2A44;fontColor=#FFFFFF;strokeColor=none;" parent="1" vertex="1">
<mxGeometry x="240" y="325" width="110" height="30" as="geometry"/>
</mxCell>
<mxCell id="5946" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;Surface&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" parent="1" vertex="1">
<mxGeometry x="260" y="325" width="70" height="30" as="geometry"/>
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>
docs/data/reference/programming_model/memory_hierarchy.svg
+1
Просмотреть файл
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 36 KiB

docs/data/reference/programming_model/thread_hierarchy.drawio
+8332
Просмотреть файл
Разница между файлами не показана из-за своего большого размера Загрузить разницу
docs/data/reference/programming_model/thread_hierarchy.svg
+3
Просмотреть файл
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 477 KiB

docs/data/reference/programming_model/thread_hierarchy_coop.drawio
+5152
Просмотреть файл
Разница между файлами не показана из-за своего большого размера Загрузить разницу
docs/data/reference/programming_model/thread_hierarchy_coop.svg
+1
Просмотреть файл
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 308 KiB

docs/data/understand/programming_model/cdna2_gcd.png
Двоичные данные
Просмотреть файл
Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 90 KiB

docs/data/understand/programming_model/cdna3_cu.png
Двоичные данные
Просмотреть файл
Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 14 KiB

docs/data/understand/programming_model/cdna3_cu_dark.png
Двоичные данные
Просмотреть файл
Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 141 KiB

docs/data/understand/programming_model/rdna3_cu.drawio
Просмотреть файл
docs/data/understand/programming_model/rdna3_cu.png
Двоичные данные
Просмотреть файл
Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 450 KiB

docs/data/understand/programming_model/simt.drawio
+148
Просмотреть файл
@@ -0,0 +1,148 @@
<mxfile host="65bd71144e">
<diagram id="zBbb_w2fufU70cdOGtND" name="1 oldal">
<mxGraphModel dx="1397" dy="443" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="0" pageScale="1" pageWidth="660" pageHeight="610" background="none" math="0" shadow="0">
<root>
<mxCell id="0"/>
<mxCell id="1" parent="0"/>
<mxCell id="6009" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#523E43;fontColor=#FFFFFF;strokeColor=none;container=0;" vertex="1" parent="1">
<mxGeometry width="320" height="380" as="geometry"/>
</mxCell>
<mxCell id="5985" value="" style="group" vertex="1" connectable="0" parent="1">
<mxGeometry x="60" y="10" width="40" height="360" as="geometry"/>
</mxCell>
<mxCell id="5947" value="" style="shape=flexArrow;endArrow=classic;html=1;width=60;endSize=16.142857142857142;endWidth=61.142857142857146;strokeColor=none;fillColor=#5E5B61;startWidth=76.3265306122449;startSize=14.045714285714284;" edge="1" parent="5985">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="20" as="sourcePoint"/>
<mxPoint x="20" y="360" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5951" value="" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="10" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5948" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5951">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5950" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;ADD&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5951">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5952" value="FM" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="110" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5953" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5952">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5954" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5952">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5955" value="FM" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="160" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5956" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5955">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5957" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5955">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5964" value="FM" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="210" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5965" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5964">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5966" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5964">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5967" value="FM" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="260" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5968" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5967">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5969" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5967">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5982" value="" style="group" vertex="1" connectable="0" parent="5985">
<mxGeometry y="60" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5983" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5982">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5984" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;DIV&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5982">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5986" value="" style="group" vertex="1" connectable="0" parent="1">
<mxGeometry x="220" y="10" width="40" height="360" as="geometry"/>
</mxCell>
<mxCell id="5987" value="" style="shape=flexArrow;endArrow=classic;html=1;width=60;endSize=16.142857142857142;endWidth=61.142857142857146;strokeColor=none;fillColor=#5E5B61;startWidth=76.3265306122449;startSize=14.045714285714284;" edge="1" parent="5986">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="20" as="sourcePoint"/>
<mxPoint x="20" y="360" as="targetPoint"/>
</mxGeometry>
</mxCell>
<mxCell id="5988" value="" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="10" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5989" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5988">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5990" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;ADD&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5988">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5991" value="FM" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="110" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5992" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5991">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5993" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5991">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5994" value="FM" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="160" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5995" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5994">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5996" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5994">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="5997" value="FM" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="210" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5998" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="5997">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="5999" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="5997">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="6000" value="FM" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="260" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="6001" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="6000">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="6002" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;FMA&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="6000">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="6003" value="" style="group" vertex="1" connectable="0" parent="5986">
<mxGeometry y="60" width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="6004" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#C23555;strokeColor=none;fontColor=#FFFFFF;" vertex="1" parent="6003">
<mxGeometry width="40" height="40" as="geometry"/>
</mxCell>
<mxCell id="6005" value="&lt;font face=&quot;Klavika&quot; style=&quot;font-size: 17px;&quot;&gt;DIV&lt;/font&gt;" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;fontSize=17;fontColor=#FFFFFF;" vertex="1" parent="6003">
<mxGeometry y="5" width="40" height="30" as="geometry"/>
</mxCell>
<mxCell id="6006" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;labelBackgroundColor=default;endArrow=classic;fontSize=11;rounded=1;strokeColor=none;endSize=16.142857142857142;fillColor=#5E5B61;startSize=14.045714285714284;" vertex="1" parent="1">
<mxGeometry x="135" y="166" width="10" height="10" as="geometry"/>
</mxCell>
<mxCell id="6007" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;labelBackgroundColor=default;endArrow=classic;fontSize=11;rounded=1;strokeColor=none;endSize=16.142857142857142;fillColor=#5E5B61;startSize=14.045714285714284;" vertex="1" parent="1">
<mxGeometry x="155" y="166" width="10" height="10" as="geometry"/>
</mxCell>
<mxCell id="6008" value="" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;labelBackgroundColor=default;endArrow=classic;fontSize=11;rounded=1;strokeColor=none;endSize=16.142857142857142;fillColor=#5E5B61;startSize=14.045714285714284;" vertex="1" parent="1">
<mxGeometry x="175" y="166" width="10" height="10" as="geometry"/>
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>
docs/data/understand/programming_model/simt.svg
+1
Просмотреть файл
Различия файлов скрыты, потому что одна или несколько строк слишком длинны
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 16 KiB

docs/developer_guide/build.md
-200
Просмотреть файл
@@ -1,200 +0,0 @@
# Building HIP from Source
## Prerequisites
HIP code can be developed either on AMD ROCm platform using HIP-Clang compiler, or a CUDA platform with nvcc installed.
Before build and run HIP, make sure drivers and pre-build packages are installed properly on the platform.
### AMD platform
Install ROCm packages or pre-built binary packages using the package manager. Refer to the ROCm Installation Guide at https://rocm.docs.amd.com for more information on installing ROCm.
```shell
sudo apt install mesa-common-dev
sudo apt install clang
sudo apt install comgr
sudo apt-get -y install rocm-dkms
sudo apt-get install -y libelf-dev
```
### NVIDIA platform
Install Nvidia driver and pre-build packages (see HIP Installation Guide at https://docs.amd.com/ for the release)
### Branch of repository
Before get HIP source code, set the expected branch of repository at the variable `ROCM_BRANCH`.
For example, for ROCm 6.1 release branch, set
```shell
export ROCM_BRANCH=rocm-6.1.x
```
ROCm5.7 release branch, set
```shell
export ROCM_BRANCH=rocm-5.7.x
```
Similiar format for future branches.
`ROCM_PATH` is path where ROCM is installed. BY default `ROCM_PATH` is at `/opt/rocm`.
## Build HIP
### Get HIP source code
A new repository 'hipother' is added in the ROCm 6.1 release, which is branched out from HIP.
The 'hipother' provides files required to support the HIP back-end implementation on some non-AMD platforms, like NVIDIA.
```shell
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/clr.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hip.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hipother.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/HIPCC.git hipcc
```
### Set the environment variables
```shell
export CLR_DIR="$(readlink -f clr)"
export HIP_DIR="$(readlink -f hip)"
export HIP_OTHER="$(readlink -f hipother)"
export HIPCC_DIR="$(readlink -f hipcc)"
```
Note, starting from ROCM 5.6 release, clr is a new repository including the previous ROCclr, HIPAMD and OpenCl repositories.
ROCclr is defined on AMD platform that HIP uses Radeon Open Compute Common Language Runtime (ROCclr), which is a virtual device interface that HIP runtimes interact with different backends.
HIPAMD provides implementation specifically for the AMD platform.
OpenCL provides headers that ROCclr runtime currently depends on.
hipother provides headers and implementation specifically for the non-AMD platform, like NVIDIA.
### Build the HIPCC runtime
```shell
cd "$HIPCC_DIR"
mkdir -p build; cd build
cmake ..
make -j4
```
### Build HIP on the AMD platform
#### Build HIP runtime
Commands to build HIP runtime on the AMD platform are as following. The option 'HIP_PLATFORM=amd' should be defined.
```shell
cd "$CLR_DIR"
mkdir -p build; cd build
cmake -DHIP_COMMON_DIR=$HIP_DIR -DHIP_PLATFORM=amd -DCMAKE_PREFIX_PATH="/opt/rocm/" -DCMAKE_INSTALL_PREFIX=$PWD/install -DHIPCC_BIN_DIR=$HIPCC_DIR/build -DHIP_CATCH_TEST=0 -DCLR_BUILD_HIP=ON -DCLR_BUILD_OCL=OFF ..
make -j$(nproc)
sudo make install
```
Note, if `CMAKE_INSTALL_PREFIX` is not specified, hip runtime will be installed to `<ROCM_PATH>/hip`.
By default, release version of HIP is built.
#### Default paths and environment variables
* By default HIP looks for HSA in `<ROCM_PATH>/hsa` (can be overridden by setting `HSA_PATH` environment variable).
* By default HIP is installed into `<ROCM_PATH>/hip`.
* By default HIP looks for clang in `<ROCM_PATH>/llvm/bin` (can be overridden by setting `HIP_CLANG_PATH` environment variable)
* By default HIP looks for device library in `<ROCM_PATH>/lib` (can be overridden by setting `DEVICE_LIB_PATH` environment variable).
* Optionally, consider adding `<ROCM_PATH>/bin` to your `PATH` to make it easier to use the tools.
* Optionally, set `HIPCC_VERBOSE=7` to output the command line for compilation.
#### Generate profiling header after adding/changing a HIP API
When you add or change a HIP API, you must generate a new `hip_prof_str.h` header. ROCm tools like ROCProfiler and ROCTracer use this header to track HIP APIs.
To generate the header after your change, use the tool `hip_prof_gen.py` present in `hipamd/src`.
Usage:
`hip_prof_gen.py [-v] <input HIP API .h file> <patched srcs path> <previous output> [<output>]`
Flags:
* -v - verbose messages
* -r - process source directory recursively
* -t - API types matching check
* --priv - private API check
* -e - on error exit mode
* -p - HIP_INIT_API macro patching mode
Example Usage:
```shell
hip_prof_gen.py -v -p -t --priv <hip>/include/hip/hip_runtime_api.h \
<hipamd>/src <hipamd>/include/hip/amd_detail/hip_prof_str.h \
<hipamd>/include/hip/amd_detail/hip_prof_str.h.new
```
#### Build HIP tests
HIP catch tests, with the newly architectured Catch2, are officially separated from the HIP project. The HIP catch tests are moved to the HIP tests repository and can be built using the instructions in the following sections.
##### Get HIP tests source code
```shell
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hip-tests.git
```
##### Build HIP tests from source
```shell
export HIPTESTS_DIR="$(readlink -f hip-tests)"
cd "$HIPTESTS_DIR"
mkdir -p build; cd build
cmake ../catch -DHIP_PLATFORM=amd -DHIP_PATH=$CLR_DIR/build/install # or any path where HIP is installed, for example, /opt/rocm.
make -j$(nproc) build_tests # build tests
cd build/catch_tests && ctest # to run all tests.
```
HIP catch tests are built under the folder $HIPTESTS_DIR/build.
Note that when using ctest, you can use different ctest options, for example, to run all tests with the keyword hipMemset,
```
ctest -R hipMemset
```
Use the below option will print test failures for failed tests,
```
ctest --output-on-failure
```
For more information, refer to https://cmake.org/cmake/help/v3.5/manual/ctest.1.html.
To run any single catch test, the following is an example,
```shell
cd $HIPTESTS_DIR/build/catch_tests/unit/texture
./TextureTest
```
##### Build HIP Catch2 standalone tests
HIP Catch2 supports building standalone tests, for example,
```shell
cd "$HIPTESTS_DIR"
hipcc $HIPTESTS_DIR/catch/unit/memory/hipPointerGetAttributes.cc -I ./catch/include ./catch/hipTestMain/standalone_main.cc -I ./catch/external/Catch2 -o hipPointerGetAttributes
./hipPointerGetAttributes
...
All tests passed
```
### Build HIP on the NVIDIA platform
#### Build HIP runtime
Commands to build HIP on the NVIDIA platform are as following. The options 'HIPNV_DIR=$HIP_OTHER/hipnv' and 'HIP_PLATFORM=nvidia' should be defined.
```shell
cd "$CLR_DIR"
mkdir -p build; cd build
cmake -DHIP_COMMON_DIR=$HIP_DIR -DCMAKE_PREFIX_PATH="/opt/rocm/" -DCMAKE_INSTALL_PREFIX=$PWD/install -DHIPCC_BIN_DIR=$HIPCC_DIR/build -DHIP_CATCH_TEST=0 -DCLR_BUILD_HIP=ON -DCLR_BUILD_OCL=OFF -DHIPNV_DIR=$HIP_OTHER/hipnv -DHIP_PLATFORM=nvidia ..
make -j$(nproc)
sudo make install
```
#### Build HIP tests
Build HIP tests commands on NVIDIA platform are basically the same as AMD, except set `-DHIP_PLATFORM=nvidia`.
## Run HIP
Compile and run the [square sample](https://github.com/ROCm/hip-tests/tree/rocm-6.0.x/samples/0_Intro/square).
docs/developer_guide/logging.md
-233
Просмотреть файл
@@ -1,233 +0,0 @@
# Logging Mechanisms
HIP provides a logging mechanism, which is a convenient way of printing
important information so as to trace HIP API and runtime codes during the
execution of HIP application.
It assists HIP development team in the development of HIP runtime, and is useful
for HIP application developers as well.
Depending on the setting of logging level and logging mask, HIP logging will
print different kinds of information, for different types of functionalities
such as HIP APIs, executed kernels, queue commands and queue contents, etc.
## HIP Logging Level:
By default, HIP logging is disabled, it can be enabled via the `AMD_LOG_LEVEL`
environment variable.
The value controls the logging level. The levels are defined as:
```cpp
enum LogLevel {
LOG_NONE = 0,
LOG_ERROR = 1,
LOG_WARNING = 2,
LOG_INFO = 3,
LOG_DEBUG = 4
};
```
## HIP Logging Mask:
Logging mask is designed to print types of functionalities during the execution
of HIP application.
It can be set as one of the following values,
```cpp
enum LogMask {
LOG_API = 1, //!< (0x1) API call
LOG_CMD = 2, //!< (0x2) Kernel and Copy Commands and Barriers
LOG_WAIT = 4, //!< (0x4) Synchronization and waiting for commands to finish
LOG_AQL = 8, //!< (0x8) Decode and display AQL packets
LOG_QUEUE = 16, //!< (0x10) Queue commands and queue contents
LOG_SIG = 32, //!< (0x20) Signal creation, allocation, pool
LOG_LOCK = 64, //!< (0x40) Locks and thread-safety code.
LOG_KERN = 128, //!< (0x80) Kernel creations and arguments, etc.
LOG_COPY = 256, //!< (0x100) Copy debug
LOG_COPY2 = 512, //!< (0x200) Detailed copy debug
LOG_RESOURCE = 1024, //!< (0x400) Resource allocation, performance-impacting events.
LOG_INIT = 2048, //!< (0x800) Initialization and shutdown
LOG_MISC = 4096, //!< (0x1000) Misc debug, not yet classified
LOG_AQL2 = 8192, //!< (0x2000) Show raw bytes of AQL packet
LOG_CODE = 16384, //!< (0x4000) Show code creation debug
LOG_CMD2 = 32768, //!< (0x8000) More detailed command info, including barrier commands
LOG_LOCATION = 65536, //!< (0x10000) Log message location
LOG_MEM = 131072, //!< (0x20000) Memory allocation
LOG_MEM_POOL = 262144, //!< (0x40000) Memory pool allocation, including memory in graphs
LOG_ALWAYS = -1 //!< (0xFFFFFFFF) Log always even mask flag is zero
};
```
Once `AMD_LOG_LEVEL` is set, logging mask is set as default with the value
`-1`.
However, for different purpose of logging functionalities, logging mask can be
defined as well via environment variable `AMD_LOG_MASK`
## HIP Logging command:
To pring HIP logging information, the function is defined as
```cpp
#define ClPrint(level, mask, format, ...) \
do { \
if (AMD_LOG_LEVEL >= level) { \
if (AMD_LOG_MASK & mask || mask == amd::LOG_ALWAYS) { \
if (AMD_LOG_MASK & amd::LOG_LOCATION) { \
amd::log_printf(level, __FILENAME__, __LINE__, format, ##__VA_ARGS__);\
} else { \
amd::log_printf(level, "", 0, format, ##__VA_ARGS__); \
} \
} \
} \
} while (false)
```
So in HIP code, call `ClPrint()` function with proper input varibles as needed,
for example,
```cpp
ClPrint(amd::LOG_INFO, amd::LOG_INIT, "Initializing HSA stack.");
```
## HIP Logging Example:
Below is an example to enable HIP logging and get logging information during execution of hipinfo on Linux,
```console
user@user-test:~/hip/bin$ export AMD_LOG_LEVEL=4
user@user-test:~/hip/bin$ ./hipinfo
:3:rocdevice.cpp :444 : 115921848303 us: [pid:177158 tid:0x7f941a0d5a80] Initializing HSA stack.
:3:comgrctx.cpp :33 : 115921854454 us: [pid:177158 tid:0x7f941a0d5a80] Loading COMGR library.
:3:rocdevice.cpp :210 : 115921854490 us: [pid:177158 tid:0x7f941a0d5a80] Numa selects cpu agent[0]=0xcc4ef0(fine=0xbbffe0,coarse=0xcc53d0) for gpu agent=0xcc59c0 CPU<->GPU XGMI=0
:3:rocdevice.cpp :1680: 115921854758 us: [pid:177158 tid:0x7f941a0d5a80] Gfx Major/Minor/Stepping: 10/3/1
:3:rocdevice.cpp :1682: 115921854764 us: [pid:177158 tid:0x7f941a0d5a80] HMM support: 1, XNACK: 0, Direct host access: 0
:3:rocdevice.cpp :1684: 115921854766 us: [pid:177158 tid:0x7f941a0d5a80] Max SDMA Read Mask: 0x3, Max SDMA Write Mask: 0x3
:4:rocdevice.cpp :2063: 115921854812 us: [pid:177158 tid:0x7f941a0d5a80] Allocate hsa host memory 0x7f941a179000, size 0x38
:4:rocdevice.cpp :2063: 115921855244 us: [pid:177158 tid:0x7f941a0d5a80] Allocate hsa host memory 0x7f930c400000, size 0x101000
:4:rocdevice.cpp :2063: 115921856057 us: [pid:177158 tid:0x7f941a0d5a80] Allocate hsa host memory 0x7f930c200000, size 0x101000
:4:runtime.cpp :83 : 115921856451 us: [pid:177158 tid:0x7f941a0d5a80] init
:3:hip_context.cpp :48 : 115921856457 us: [pid:177158 tid:0x7f941a0d5a80] Direct Dispatch: 1
:3:hip_device_runtime.cpp :546 : 115921856476 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceCount ( 0x7ffc69af52e4 )
:3:hip_device_runtime.cpp :548 : 115921856479 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceCount: Returned hipSuccess :
:3:hip_device_runtime.cpp :561 : 115921856484 us: [pid:177158 tid:0x7f941a0d5a80] hipSetDevice ( 0 )
:3:hip_device_runtime.cpp :565 : 115921856488 us: [pid:177158 tid:0x7f941a0d5a80] hipSetDevice: Returned hipSuccess :
--------------------------------------------------------------------------------
device# 0
:3:hip_device.cpp :381 : 115921856498 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceProperties ( 0x7ffc69af4fa0, 0 )
:3:hip_device.cpp :383 : 115921856502 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceProperties: Returned hipSuccess :
Name: AMD Radeon RX 6700 XT
pciBusID: 3
pciDeviceID: 0
pciDomainID: 0
multiProcessorCount: 20
maxThreadsPerMultiProcessor: 2048
isMultiGpuBoard: 0
clockRate: 2855 Mhz
memoryClockRate: 1000 Mhz
memoryBusWidth: 192
totalGlobalMem: 11.98 GB
totalConstMem: 2147483647
sharedMemPerBlock: 64.00 KB
canMapHostMemory: 1
regsPerBlock: 65536
warpSize: 32
l2CacheSize: 3145728
computeMode: 0
maxThreadsPerBlock: 1024
maxThreadsDim.x: 1024
maxThreadsDim.y: 1024
maxThreadsDim.z: 1024
maxGridSize.x: 2147483647
maxGridSize.y: 65536
maxGridSize.z: 65536
major: 10
minor: 3
concurrentKernels: 1
cooperativeLaunch: 1
cooperativeMultiDeviceLaunch: 1
isIntegrated: 0
maxTexture1D: 16384
maxTexture2D.width: 16384
maxTexture2D.height: 16384
maxTexture3D.width: 16384
maxTexture3D.height: 16384
maxTexture3D.depth: 8192
isLargeBar: 0
asicRevision: 0
maxSharedMemoryPerMultiProcessor: 64.00 KB
clockInstructionRate: 1000.00 Mhz
...
gcnArchName: gfx1031
:3:hip_device_runtime.cpp :546 : 115921856613 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceCount ( 0x7ffc69af4f8c )
:3:hip_device_runtime.cpp :548 : 115921856616 us: [pid:177158 tid:0x7f941a0d5a80] hipGetDeviceCount: Returned hipSuccess :
:3:hip_peer.cpp :176 : 115921856625 us: [pid:177158 tid:0x7f941a0d5a80] hipDeviceCanAccessPeer ( 0x7ffc69af4f90, 0, 0 )
:3:hip_peer.cpp :177 : 115921856628 us: [pid:177158 tid:0x7f941a0d5a80] hipDeviceCanAccessPeer: Returned hipSuccess :
peers:
:3:hip_peer.cpp :176 : 115921856633 us: [pid:177158 tid:0x7f941a0d5a80] hipDeviceCanAccessPeer ( 0x7ffc69af4f90, 0, 0 )
:3:hip_peer.cpp :177 : 115921856636 us: [pid:177158 tid:0x7f941a0d5a80] hipDeviceCanAccessPeer: Returned hipSuccess :
non-peers: device#0
:3:hip_memory.cpp :764 : 115921856649 us: [pid:177158 tid:0x7f941a0d5a80] hipMemGetInfo ( 0x7ffc69af4f90, 0x7ffc69af4f98 )
:3:hip_memory.cpp :788 : 115921856654 us: [pid:177158 tid:0x7f941a0d5a80] hipMemGetInfo: Returned hipSuccess :
memInfo.total: 11.98 GB
memInfo.free: 11.86 GB (99%)
```
On Windows, AMD_LOG_LEVEL can be set via environment variable from advanced system setting, or from Command prompt run as administrator, as shown below as an example, which shows some debug log information calling backend runtime on Windows.
```
C:\hip\bin>set AMD_LOG_LEVEL=4
C:\hip\bin>hipinfo
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\comgrctx.cpp:33 : 605413686305 us: 29864: [tid:0x9298] Loading COMGR library.
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\platform\runtime.cpp:83 : 605413869411 us: 29864: [tid:0x9298] init
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_context.cpp:47 : 605413869502 us: 29864: [tid:0x9298] Direct Dispatch: 0
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:543 : 605413870553 us: 29864: [tid:0x9298] hipGetDeviceCount: Returned hipSuccess :
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:556 : 605413870631 us: 29864: [tid:0x9298] ←[32m hipSetDevice ( 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:561 : 605413870848 us: 29864: [tid:0x9298] hipSetDevice: Returned hipSuccess :
--------------------------------------------------------------------------------
device# 0
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device.cpp:346 : 605413871623 us: 29864: [tid:0x9298] ←[32m hipGetDeviceProperties ( 0000008AEBEFF8C8, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device.cpp:348 : 605413871695 us: 29864: [tid:0x9298] hipGetDeviceProperties: Returned hipSuccess :
Name: AMD Radeon(TM) Graphics
pciBusID: 3
pciDeviceID: 0
pciDomainID: 0
multiProcessorCount: 7
maxThreadsPerMultiProcessor: 2560
isMultiGpuBoard: 0
clockRate: 1600 Mhz
memoryClockRate: 1333 Mhz
memoryBusWidth: 0
totalGlobalMem: 12.06 GB
totalConstMem: 2147483647
sharedMemPerBlock: 64.00 KB
...
gcnArchName: gfx90c:xnack-
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:541 : 605413924779 us: 29864: [tid:0x9298] ←[32m hipGetDeviceCount ( 0000008AEBEFF8A4 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:543 : 605413925075 us: 29864: [tid:0x9298] hipGetDeviceCount: Returned hipSuccess :
peers: :3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:176 : 605413928643 us: 29864: [tid:0x9298] ←[32m hipDeviceCanAccessPeer ( 0000008AEBEFF890, 0, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:177 : 605413928743 us: 29864: [tid:0x9298] hipDeviceCanAccessPeer: Returned hipSuccess :
non-peers: :3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:176 : 605413930830 us: 29864: [tid:0x9298] ←[32m hipDeviceCanAccessPeer ( 0000008AEBEFF890, 0, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:177 : 605413930882 us: 29864: [tid:0x9298] hipDeviceCanAccessPeer: Returned hipSuccess :
device#0
...
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:430 : 605414517802 us: 29864: [tid:0x9298] Free-: 8000 bytes, VM[ 3007c8000, 3007d0000]
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\devprogram.cpp:2979: 605414517893 us: 29864: [tid:0x9298] For Init/Fini: Kernel Name: __amd_rocclr_copyBufferToImage
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\devprogram.cpp:2979: 605414518259 us: 29864: [tid:0x9298] For Init/Fini: Kernel Name: __amd_rocclr_copyBuffer
...
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:206 : 605414523422 us: 29864: [tid:0x9298] Alloc: 100000 bytes, ptr[00000003008D0000-00000003009D0000], obj[00000003007D0000-00000003047D0000]
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:206 : 605414523767 us: 29864: [tid:0x9298] Alloc: 100000 bytes, ptr[00000003009D0000-0000000300AD0000], obj[00000003007D0000-00000003047D0000]
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_memory.cpp:681 : 605414524092 us: 29864: [tid:0x9298] hipMemGetInfo: Returned hipSuccess :
memInfo.total: 12.06 GB
memInfo.free: 11.93 GB (99%)
```
## HIP Logging Tips:
- HIP logging works for both release and debug version of HIP application.
- Logging function with different logging level can be called in the code as
needed.
- Information with logging level less than AMD_LOG_LEVEL will be printed.
- If need to save the HIP logging output information in a file, just define the
file at the command when run the application at the terminal, for example,
```console
user@user-test:~/hip/bin$ ./hipinfo > ~/hip_log.txt
```
docs/doxygen/Doxyfile
+2 -1
Просмотреть файл
@@ -831,7 +831,8 @@ WARN_LOGFILE =
INPUT = mainpage.md \
../../include/hip \
../../../clr/hipamd/include/hip/amd_detail/amd_hip_gl_interop.h
../../../clr/hipamd/include/hip/amd_detail/amd_hip_gl_interop.h \
../../../llvm-project/clang/lib/Headers/__clang_hip_math.h
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
docs/doxygen/mainpage.md
+1
Просмотреть файл
@@ -4,6 +4,7 @@ This is the full HIP Runtime API reference. The API is organized into
[modules](modules.html) based on functionality.
## List of Modules
- @ref GlobalDefs
- @ref Driver
- @ref Device
docs/how-to/debugging.rst
+382
Просмотреть файл
@@ -0,0 +1,382 @@
.. meta::
:description: How to debug using HIP.
:keywords: AMD, ROCm, HIP, debugging, ltrace, ROCdgb, Windgb
*************************************************************************
Debugging with HIP
*************************************************************************
AMD debugging tools include *ltrace* and *ROCdgb*. External tools are available and can be found
online. For example, if you're using Windows, you can use *Microsoft Visual Studio* and *Windgb*.
You can trace and debug your code using the following tools and techniques.
Tracing
================================================
You can use tracing to quickly observe the flow of an application before reviewing the detailed
information provided by a command-line debugger. Tracing can be used to identify issues ranging
from accidental API calls to calls made on a critical path.
ltrace is a standard Linux tool that provides a message to ``stderr`` on every dynamic library call. You
can use ltrace to visualize the runtime behavior of the entire ROCm software stack.
Here's a simple command-line example that uses ltrace to trace HIP APIs and output:
.. code:: console
$ ltrace -C -e "hip*" ./hipGetChanDesc
hipGetChanDesc->hipCreateChannelDesc(0x7ffdc4b66860, 32, 0, 0) = 0x7ffdc4b66860
hipGetChanDesc->hipMallocArray(0x7ffdc4b66840, 0x7ffdc4b66860, 8, 8) = 0
hipGetChanDesc->hipGetChannelDesc(0x7ffdc4b66848, 0xa63990, 5, 1) = 0
hipGetChanDesc->hipFreeArray(0xa63990, 0, 0x7f8c7fe13778, 0x7ffdc4b66848) = 0
PASSED!
+++ exited (status 0) +++
Here's another example that uses ltrace to trace hsa APIs and output:
.. code:: console
$ ltrace -C -e "hsa*" ./hipGetChanDesc
libamdhip64.so.4->hsa_init(0, 0x7fff325a69d0, 0x9c80e0, 0 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtOpenKFD(0x7fff325a6590, 0x9c38c0, 0, 1) = 0
libhsa-runtime64.so.1->hsaKmtGetVersion(0x7fff325a6608, 0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtReleaseSystemProperties(3, 0x80084b01, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtAcquireSystemProperties(0x7fff325a6610, 0, 0, 1) = 0
libhsa-runtime64.so.1->hsaKmtGetNodeProperties(0, 0x7fff325a66a0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtGetNodeMemoryProperties(0, 1, 0x9c42b0, 0x936012) = 0
...
<... hsaKmtCreateEvent resumed> ) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 64, 0x7fff325a6690) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f1202749000, 4096, 0x7fff325a6690, 0) = 0
libhsa-runtime64.so.1->hsaKmtCreateEvent(0x7fff325a6700, 0, 0, 0x7fff325a66f0) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(1, 0x100000000, 576, 0x7fff325a67d8) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 8192, 64, 0x7fff325a6790) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f120273c000, 8192, 0x7fff325a6790, 0) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 4160, 0x7fff325a6450) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f120273a000, 4096, 0x7fff325a6450, 0) = 0
libhsa-runtime64.so.1->hsaKmtSetTrapHandler(1, 0x7f120273a000, 4096, 0x7f120273c000) = 0
<... hsa_init resumed> ) = 0
libamdhip64.so.4->hsa_system_get_major_extension_table(513, 1, 24, 0x7f1202597930) = 0
libamdhip64.so.4->hsa_iterate_agents(0x7f120171f050, 0, 0x7fff325a67f8, 0 <unfinished ...>
libamdhip64.so.4->hsa_agent_get_info(0x94f110, 17, 0x7fff325a67e8, 0) = 0
libamdhip64.so.4->hsa_amd_agent_iterate_memory_pools(0x94f110, 0x7f1201722816, 0x7fff325a67f0, 0x7f1201722816 <unfinished ...>
libamdhip64.so.4->hsa_amd_memory_pool_get_info(0x9c7fb0, 0, 0x7fff325a6744, 0x7fff325a67f0) = 0
libamdhip64.so.4->hsa_amd_memory_pool_get_info(0x9c7fb0, 1, 0x7fff325a6748, 0x7f1200d82df4) = 0
...
<... hsa_amd_agent_iterate_memory_pools resumed> ) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 17, 0x7fff325a67e8, 0) = 0
<... hsa_iterate_agents resumed> ) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 0, 0x7fff325a6850, 3) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 0xa000, 0x9e7cd8, 0) = 0
libamdhip64.so.4->hsa_agent_iterate_isas(0x9dbf30, 0x7f1201720411, 0x7fff325a6760, 0x7f1201720411) = 0
libamdhip64.so.4->hsa_isa_get_info_alt(0x94e7c8, 0, 0x7fff325a6728, 1) = 0
libamdhip64.so.4->hsa_isa_get_info_alt(0x94e7c8, 1, 0x9e7f90, 0) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 4, 0x9e7ce8, 0) = 0
...
<... hsa_amd_memory_pool_allocate resumed> ) = 0
libamdhip64.so.4->hsa_ext_image_create(0x9dbf30, 0xa1c4c8, 0x7f10f2800000, 3 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 64, 0x7fff325a6740) = 0
libhsa-runtime64.so.1->hsaKmtQueryPointerInfo(0x7f1202736000, 0x7fff325a65e0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f1202736000, 4096, 0x7fff325a66e8, 0) = 0
<... hsa_ext_image_create resumed> ) = 0
libamdhip64.so.4->hsa_ext_image_destroy(0x9dbf30, 0x7f1202736000, 0x9dbf30, 0 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtUnmapMemoryToGPU(0x7f1202736000, 0x7f1202736000, 4096, 0x9c8050) = 0
libhsa-runtime64.so.1->hsaKmtFreeMemory(0x7f1202736000, 4096, 0, 0) = 0
<... hsa_ext_image_destroy resumed> ) = 0
libamdhip64.so.4->hsa_amd_memory_pool_free(0x7f10f2800000, 0x7f10f2800000, 256, 0x9e76f0) = 0
PASSED!
Debugging
================================================
You can use ROCgdb for debugging and profiling.
ROCgdb is the ROCm source-level debugger for Linux and is based on GNU Project debugger (GDB).
the GNU source-level debugger, equivalent of cuda-gdb, can be used with debugger frontends, such as eclipse, vscode, or gdb-dashboard.
For details, see (https://github.com/ROCm/ROCgdb).
Below is a sample how to use ROCgdb run and debug HIP application, rocgdb is installed with ROCM package in the folder /opt/rocm/bin.
.. code:: console
$ export PATH=$PATH:/opt/rocm/bin
$ rocgdb ./hipTexObjPitch
GNU gdb (rocm-dkms-no-npi-hipclang-6549) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
For bug reporting instructions, please see:
<https://github.com/ROCm/ROCgdb/issues>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
...
Reading symbols from ./hipTexObjPitch...
(gdb) break main
Breakpoint 1 at 0x4013d1: file /home/test/hip/tests/src/texture/hipTexObjPitch.cpp, line 98.
(gdb) run
Starting program: /home/test/hip/build/directed_tests/texture/hipTexObjPitch
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main ()
at /home/test/hip/tests/src/texture/hipTexObjPitch.cpp:98
98 texture2Dtest<float>();
(gdb)c
Debugging HIP applications
--------------------------------------------------------------------------------------------
The following Linux example shows how to get useful information from the debugger while running a
simple memory copy test, which caused a segmentation fault issue.
.. code:: console
test: simpleTest2<?> numElements=4194304 sizeElements=4194304 bytes
Segmentation fault (core dumped)
(gdb) run
Starting program: /home/test/hipamd/build/directed_tests/runtimeApi/memory/hipMemcpy_simple
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=1, argv=0x7fffffffdea8)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:147
147 int main(int argc, char* argv[]) {
(gdb) c
Continuing.
[New Thread 0x7ffff64c4700 (LWP 146066)]
Thread 1 "hipMemcpy_simpl" received signal SIGSEGV, Segmentation fault.
0x000000000020f78e in simpleTest2<float> (numElements=4194304, usePinnedHost=true)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:104
104 A_h1[i] = 3.14f + 1000 * i;
(gdb) bt
#0 0x000000000020f78e in simpleTest2<float> (numElements=4194304, usePinnedHost=true)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:104
#1 0x000000000020e96c in main (argc=<optimized out>, argv=<optimized out>)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:163
(gdb) info thread
Id Target Id Frame
* 1 Thread 0x7ffff64c5880 (LWP 146060) "hipMemcpy_simpl" 0x000000000020f78e in simpleTest2<float> (numElements=4194304, usePinnedHost=true)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:104
2 Thread 0x7ffff64c4700 (LWP 146066) "hipMemcpy_simpl" 0x00007ffff6b0850b in ioctl
() from /lib/x86_64-linux-gnu/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff64c4700 (LWP 146066))]
#0 0x00007ffff6b0850b in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff6b0850b in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff6604568 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#2 0x00007ffff65fe73a in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#3 0x00007ffff659e4d6 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#4 0x00007ffff65807de in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#5 0x00007ffff65932a2 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#6 0x00007ffff654f547 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#7 0x00007ffff7f76609 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#8 0x00007ffff6b13293 in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff64c5880 (LWP 146060))]
#0 0x000000000020f78e in simpleTest2<float> (numElements=4194304, usePinnedHost=true)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:104
104 A_h1[i] = 3.14f + 1000 * i;
(gdb) bt
#0 0x000000000020f78e in simpleTest2<float> (numElements=4194304, usePinnedHost=true)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:104
#1 0x000000000020e96c in main (argc=<optimized out>, argv=<optimized out>)
at /home/test/hip/tests/src/runtimeApi/memory/hipMemcpy_simple.cpp:163
(gdb)
...
Debugging HIP applications using Windows tools can be more informative than on Linux. Windows
tools provides more visibility into debug codes, which makes it easier to inspect variables, watch
multiple details, and examine call stacks.
Useful environment variables
===================================================
HIP provides environment variables that allow HIP, hip-clang, or HSA drivers to prevent certain features
and optimizations. These are not intended for production, but can be useful to diagnose
synchronization problems in the application (or driver).
Some of the more widely used environment variables are described in this section. These are
supported on the Linux ROCm path and Windows.
Kernel enqueue serialization
---------------------------------------------------------------------------------
You can control kernel command serialization from the host:
``AMD_SERIALIZE_KERNEL``, for serializing kernel enqueue
``AMD_SERIALIZE_KERNEL = 1``, Wait for completion before enqueue
``AMD_SERIALIZE_KERNEL = 2``, Wait for completion after enqueue
``AMD_SERIALIZE_KERNEL = 3``, Both
Or
``AMD_SERIALIZE_COPY``, for serializing copies
``AMD_SERIALIZE_COPY = 1``, Wait for completion before enqueue
``AMD_SERIALIZE_COPY = 2``, Wait for completion after enqueue
``AMD_SERIALIZE_COPY = 3``, Both
So HIP runtime can wait for GPU idle before/after any GPU command depending on the environment
setting.
Making device visible
---------------------------------------------------------------------------------
For systems with multiple devices, you can choose to make only certain device(s) visible to HIP using
``HIP_VISIBLE_DEVICES`` (or ``CUDA_VISIBLE_DEVICES`` on an NVIDIA platform). Once enabled, HIP can
only view devices that have indices present in the sequence. For example:
.. code:: console
$ HIP_VISIBLE_DEVICES=0,1
Or in the application:
.. code:: cpp
if (totalDeviceNum > 2) {
setenv("HIP_VISIBLE_DEVICES", "0,1,2", 1);
assert(getDeviceNumber(false) == 3);
... ...
}
Dump code object
---------------------------------------------------------------------------------
To analyze compiler-related issues, you can use the dump code object:
``GPU_DUMP_CODE_OBJECT``.
HSA-related environment variables (Linux)
-----------------------------------------------------------------------------------------------
HSA provides environment variables that help analyze issues in drivers or hardware.
* To isolate issues with hardware copy engines, you can use ``HSA_ENABLE_SDMA``.
``HSA_ENABLE_SDMA=0`` causes host-to-device and device-to-host copies to use compute shader
blit kernels, rather than the dedicated DMA copy engines. Compute shader copies have low latency
(typically < 5 us) and can achieve approximately 80% of the bandwidth of the DMA copy engine.
* To diagnose interrupt storm issues in the driver, you can use ``HSA_ENABLE_INTERRUPT``.
``HSA_ENABLE_INTERRUPT=0`` causes completion signals to be detected with memory-based
polling, rather than interrupts.
HIP environment variable summary
-----------------------------------------------------------------------------------------------
Here are some of the more commonly used environment variables:
.. list-table::
* - **Environment variable**
- **Default value**
- **Usage**
* - AMD_LOG_LEVEL
| <sub>Enable HIP log on different Level</sub>
- 0
- 0: Disable log.
| 1: Enable log on error level
| 2: Enable log on warning and below levels
| 0x3: Enable log on information and below levels
| 0x4: Decode and display AQL packets
* - AMD_LOG_MASK
| <sub>Enable HIP log on different Level</sub>
- 0x7FFFFFFF
- 0x1: Log API calls
| 0x02: Kernel and Copy Commands and Barriers
| 0x4: Synchronization and waiting for commands to finish
| 0x8: Enable log on information and below levels
| 0x20: Queue commands and queue contents
| 0x40: Signal creation, allocation, pool
| 0x80: Locks and thread-safety code
| 0x100: Copy debug
| 0x200: Detailed copy debug
| 0x400: Resource allocation, performance-impacting events
| 0x800: Initialization and shutdown
| 0x1000: Misc debug, not yet classified
| 0x2000: Show raw bytes of AQL packet
| 0x4000: Show code creation debug
| 0x8000: More detailed command info, including barrier commands
| 0x10000: Log message location
| 0xFFFFFFFF: Log always even mask flag is zero
* - HIP_VISIBLE_DEVICES (or CUDA_VISIBLE_DEVICES)
| <sub> Only devices whose index is present in the sequence are visible to HIP</sub>
-
- 0,1,2: Depending on the number of devices on the system
* - GPU_DUMP_CODE_OBJECT
| <sub>Dump code object</sub>
- 0
- 0: Disable
| 1: Enable
* - AMD_SERIALIZE_KERNEL
| <sub> Serialize kernel enqueue</sub>
- 0
- 1: Wait for completion before enqueue
| 2: Wait for completion after enqueue
| 3: Both
* - AMD_SERIALIZE_COPY
| <sub>Serialize copies</sub>
- 0
- 1: Wait for completion before enqueue
| 2: Wait for completion after enqueue
| 3: Both
* - HIP_HOST_COHERENT
| <sub>Coherent memory in hipHostMalloc</sub>
- 0
- 0: memory is not coherent between host and GPU
| 1: memory is coherent with host
* - AMD_DIRECT_DISPATCH
| <sub> Enable direct kernel dispatch (Currently for Linux; under development for Windows)</sub>
- 1
- 0: Disable
| 1: Enable
* - GPU_MAX_HW_QUEUES
| <sub>The maximum number of hardware queues allocated per device</sub>
- 4
- The variable controls how many independent hardware queues HIP runtime can create per process,
per device. If an application allocates more HIP streams than this number, then HIP runtime reuses
the same hardware queues for the new streams in a round-robin manner. Note that this maximum
number does not apply to hardware queues that are created for CU-masked HIP streams, or
cooperative queues for HIP Cooperative Groups (single queue per device).
General debugging tips
======================================================
* ``gdb --args`` can be used to pass the executable and arguments to gdb.
* Uou can set environment variables (``set env``) from within GDB on Linux (note that this command
doesn't use an equal (=) sign:
.. code:: bash
(gdb) set env AMD_SERIALIZE_KERNEL 3
* The GDB backtrace shows a path in the runtime. This is because a fault is caught by the runtime, but
it is generated by an asynchronous command running on the GPU.
* To determine the true location of a fault, you can force the kernels to run synchronously by setting
the environment variables ``AMD_SERIALIZE_KERNEL=3`` and ``AMD_SERIALIZE_COPY=3``. This
forces HIP runtime to wait for the kernel to finish running before retuning. If the fault occurs when
a kernel is running, you can see the code that launched the kernel inside the backtrace. The thread
that's causing the issue is typically the one inside ``libhsa-runtime64.so``.
* VM faults inside kernels can be caused by:
* Incorrect code (e.g., a for loop that extends past array boundaries)
* Memory issues, such as invalid kernel arguments (null pointers, unregistered host pointers, bad
pointers)
* Synchronization issues
* Compiler issues (incorrect code generation from the compiler)
* Runtime issues
docs/how-to/logging.rst
+240
Просмотреть файл
@@ -0,0 +1,240 @@
.. meta::
:description: HIP provides a logging mechanism that allows you to trace HIP API and runtime codes
when running a HIP application.
:keywords: AMD, ROCm, HIP, logging
**********************************************************
Generate logs
**********************************************************
HIP provides a logging mechanism that allows you to trace HIP API and runtime codes when running a
HIP application. In addition to being useful to our users/developers, the HIP development team uses
these logs to improve the HIP runtime.
By adjusting the logging settings and logging mask, you can get different types of information for
different functionalities, such as HIP APIs, executed kernels, queue commands, and queue contents.
Refer to the following sections for examples.
.. tip::
Logging works for the release and debug versions of HIP. If you want to save logging output in a file,
define the file when running the application via command line. For example:
.. code-block:: bash
user@user-test:~/hip/bin$ ./hipinfo > ~/hip_log.txt
Logging level
======================================
HIP logging is disabled by default. You can enable it via the ``AMD_LOG_LEVEL`` environment variable.
The value of this variable controls your logging level. Levels are defined as follows:
.. code-block:: cpp
enum LogLevel {
LOG_NONE = 0,
LOG_ERROR = 1,
LOG_WARNING = 2,
LOG_INFO = 3,
LOG_DEBUG = 4
};
.. tip::
You can call a logging function with different logging levels. All information under the value set for
``AMD_LOG_LEVEL`` is printed.
Logging mask
======================================
The logging mask is designed to print functionality types when you're running a HIP application.
Once you set ``AMD_LOG_LEVEL``, the logging mask is set as the default value (``0x7FFFFFFF``). You can
change this to any of the valid values:
.. code-block:: cpp
enum LogMask {
LOG_API = 0x00000001, //!< API call
LOG_CMD = 0x00000002, //!< Kernel and Copy Commands and Barriers
LOG_WAIT = 0x00000004, //!< Synchronization and waiting for commands to finish
LOG_AQL = 0x00000008, //!< Decode and display AQL packets
LOG_QUEUE = 0x00000010, //!< Queue commands and queue contents
LOG_SIG = 0x00000020, //!< Signal creation, allocation, pool
LOG_LOCK = 0x00000040, //!< Locks and thread-safety code.
LOG_KERN = 0x00000080, //!< kernel creations and arguments, etc.
LOG_COPY = 0x00000100, //!< Copy debug
LOG_COPY2 = 0x00000200, //!< Detailed copy debug
LOG_RESOURCE = 0x00000400, //!< Resource allocation, performance-impacting events.
LOG_INIT = 0x00000800, //!< Initialization and shutdown
LOG_MISC = 0x00001000, //!< misc debug, not yet classified
LOG_AQL2 = 0x00002000, //!< Show raw bytes of AQL packet
LOG_CODE = 0x00004000, //!< Show code creation debug
LOG_CMD2 = 0x00008000, //!< More detailed command info, including barrier commands
LOG_LOCATION = 0x00010000, //!< Log message location
LOG_MEM = 0x00020000, //!< Memory allocation
LOG_MEM_POOL = 0x00040000, //!< Memory pool allocation, including memory in graphs
LOG_ALWAYS = 0xFFFFFFFF, //!< Log always even mask flag is zero
};
You can also define the logging mask via the ``AMD_LOG_MASK`` environment variable.
Logging command
======================================
You can use the following code to print HIP logging information:
.. code-block:: cpp
#define ClPrint(level, mask, format, ...) \
do { \
if (AMD_LOG_LEVEL >= level) { \
if (AMD_LOG_MASK & mask || mask == amd::LOG_ALWAYS) { \
if (AMD_LOG_MASK & amd::LOG_LOCATION) { \
amd::log_printf(level, __FILENAME__, __LINE__, format, ##__VA_ARGS__);\
} else { \
amd::log_printf(level, "", 0, format, ##__VA_ARGS__); \
} \
} \
} \
} while (false)
Using HIP code, call the ``ClPrint()`` function with the desired input variables. For example:
.. code-block:: cpp
ClPrint(amd::LOG_INFO, amd::LOG_INIT, "Initializing HSA stack.");
Logging examples
======================================
On **Linux**, you can enable HIP logging and retrieve logging information when you run ``hipinfo``.
.. code-block:: console
user@user-test:~/hip/bin$ export AMD_LOG_LEVEL=4
user@user-test:~/hip/bin$ ./hipinfo
:3:rocdevice.cpp :453 : 23647210092: Initializing HSA stack.
:3:comgrctx.cpp :33 : 23647639336: Loading COMGR library.
:3:rocdevice.cpp :203 : 23647687108: Numa select cpu agent[0]=0x13407c0(fine=0x13409a0,coarse=0x1340ad0) for gpu agent=0x1346150
:4:runtime.cpp :82 : 23647698669: init
:3:hip_device_runtime.cpp :473 : 23647698869: 5617 : [7fad295dd840] hipGetDeviceCount: Returned hipSuccess
:3:hip_device_runtime.cpp :502 : 23647698990: 5617 : [7fad295dd840] hipSetDevice ( 0 )
:3:hip_device_runtime.cpp :507 : 23647699042: 5617 : [7fad295dd840] hipSetDevice: Returned hipSuccess
--------------------------------------------------------------------------------
device# 0
:3:hip_device.cpp :150 : 23647699276: 5617 : [7fad295dd840] hipGetDeviceProperties ( 0x7ffdbe7db730, 0 )
:3:hip_device.cpp :237 : 23647699335: 5617 : [7fad295dd840] hipGetDeviceProperties: Returned hipSuccess
Name: Device 7341
pciBusID: 3
pciDeviceID: 0
pciDomainID: 0
multiProcessorCount: 11
maxThreadsPerMultiProcessor: 2560
isMultiGpuBoard: 0
clockRate: 1900 Mhz
memoryClockRate: 875 Mhz
memoryBusWidth: 0
clockInstructionRate: 1000 Mhz
totalGlobalMem: 7.98 GB
maxSharedMemoryPerMultiProcessor: 64.00 KB
totalConstMem: 8573157376
sharedMemPerBlock: 64.00 KB
canMapHostMemory: 1
regsPerBlock: 0
warpSize: 32
l2CacheSize: 0
computeMode: 0
maxThreadsPerBlock: 1024
maxThreadsDim.x: 1024
maxThreadsDim.y: 1024
maxThreadsDim.z: 1024
maxGridSize.x: 2147483647
maxGridSize.y: 2147483647
maxGridSize.z: 2147483647
major: 10
minor: 12
concurrentKernels: 1
cooperativeLaunch: 0
cooperativeMultiDeviceLaunch: 0
arch.hasGlobalInt32Atomics: 1
...
gcnArch: 1012
isIntegrated: 0
maxTexture1D: 65536
maxTexture2D.width: 16384
maxTexture2D.height: 16384
maxTexture3D.width: 2048
maxTexture3D.height: 2048
maxTexture3D.depth: 2048
isLargeBar: 0
:3:hip_device_runtime.cpp :471 : 23647701557: 5617 : [7fad295dd840] hipGetDeviceCount ( 0x7ffdbe7db714 )
:3:hip_device_runtime.cpp :473 : 23647701608: 5617 : [7fad295dd840] hipGetDeviceCount: Returned hipSuccess
:3:hip_peer.cpp :76 : 23647701731: 5617 : [7fad295dd840] hipDeviceCanAccessPeer ( 0x7ffdbe7db728, 0, 0 )
:3:hip_peer.cpp :60 : 23647701784: 5617 : [7fad295dd840] canAccessPeer: Returned hipSuccess
:3:hip_peer.cpp :77 : 23647701831: 5617 : [7fad295dd840] hipDeviceCanAccessPeer: Returned hipSuccess
peers:
:3:hip_peer.cpp :76 : 23647701921: 5617 : [7fad295dd840] hipDeviceCanAccessPeer ( 0x7ffdbe7db728, 0, 0 )
:3:hip_peer.cpp :60 : 23647701965: 5617 : [7fad295dd840] canAccessPeer: Returned hipSuccess
:3:hip_peer.cpp :77 : 23647701998: 5617 : [7fad295dd840] hipDeviceCanAccessPeer: Returned hipSuccess
non-peers: device#0
:3:hip_memory.cpp :345 : 23647702191: 5617 : [7fad295dd840] hipMemGetInfo ( 0x7ffdbe7db718, 0x7ffdbe7db720 )
:3:hip_memory.cpp :360 : 23647702243: 5617 : [7fad295dd840] hipMemGetInfo: Returned hipSuccess
memInfo.total: 7.98 GB
memInfo.free: 7.98 GB (100%)
On **Windows**, you can set ``AMD_LOG_LEVEL`` via environment variable from the advanced system
settings or the command prompt (when run as administrator). The following example shows debug log
information when calling the backend runtime.
.. code-block:: bash
C:\hip\bin>set AMD_LOG_LEVEL=4
C:\hip\bin>hipinfo
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\comgrctx.cpp:33 : 605413686305 us: 29864: [tid:0x9298] Loading COMGR library.
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\platform\runtime.cpp:83 : 605413869411 us: 29864: [tid:0x9298] init
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_context.cpp:47 : 605413869502 us: 29864: [tid:0x9298] Direct Dispatch: 0
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:543 : 605413870553 us: 29864: [tid:0x9298] hipGetDeviceCount: Returned hipSuccess :
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:556 : 605413870631 us: 29864: [tid:0x9298] ←[32m hipSetDevice ( 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:561 : 605413870848 us: 29864: [tid:0x9298] hipSetDevice: Returned hipSuccess :
--------------------------------------------------------------------------------
device# 0
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device.cpp:346 : 605413871623 us: 29864: [tid:0x9298] ←[32m hipGetDeviceProperties ( 0000008AEBEFF8C8, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device.cpp:348 : 605413871695 us: 29864: [tid:0x9298] hipGetDeviceProperties: Returned hipSuccess :
Name: AMD Radeon(TM) Graphics
pciBusID: 3
pciDeviceID: 0
pciDomainID: 0
multiProcessorCount: 7
maxThreadsPerMultiProcessor: 2560
isMultiGpuBoard: 0
clockRate: 1600 Mhz
memoryClockRate: 1333 Mhz
memoryBusWidth: 0
totalGlobalMem: 12.06 GB
totalConstMem: 2147483647
sharedMemPerBlock: 64.00 KB
...
gcnArchName: gfx90c:xnack-
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:541 : 605413924779 us: 29864: [tid:0x9298] ←[32m hipGetDeviceCount ( 0000008AEBEFF8A4 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_device_runtime.cpp:543 : 605413925075 us: 29864: [tid:0x9298] hipGetDeviceCount: Returned hipSuccess :
peers: :3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:176 : 605413928643 us: 29864: [tid:0x9298] ←[32m hipDeviceCanAccessPeer ( 0000008AEBEFF890, 0, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:177 : 605413928743 us: 29864: [tid:0x9298] hipDeviceCanAccessPeer: Returned hipSuccess :
non-peers: :3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:176 : 605413930830 us: 29864: [tid:0x9298] ←[32m hipDeviceCanAccessPeer ( 0000008AEBEFF890, 0, 0 ) ←[0m
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_peer.cpp:177 : 605413930882 us: 29864: [tid:0x9298] hipDeviceCanAccessPeer: Returned hipSuccess :
device#0
...
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:430 : 605414517802 us: 29864: [tid:0x9298] Free-: 8000 bytes, VM[ 3007c8000, 3007d0000]
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\devprogram.cpp:2979: 605414517893 us: 29864: [tid:0x9298] For Init/Fini: Kernel Name: __amd_rocclr_copyBufferToImage
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\devprogram.cpp:2979: 605414518259 us: 29864: [tid:0x9298] For Init/Fini: Kernel Name: __amd_rocclr_copyBuffer
...
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:206 : 605414523422 us: 29864: [tid:0x9298] Alloc: 100000 bytes, ptr[00000003008D0000-00000003009D0000], obj[00000003007D0000-00000003047D0000]
:4:C:\constructicon\builds\gfx\two\22.40\drivers\compute\vdi\device\pal\palmemory.cpp:206 : 605414523767 us: 29864: [tid:0x9298] Alloc: 100000 bytes, ptr[00000003009D0000-0000000300AD0000], obj[00000003007D0000-00000003047D0000]
:3:C:\constructicon\builds\gfx\two\22.40\drivers\compute\hipamd\src\hip_memory.cpp:681 : 605414524092 us: 29864: [tid:0x9298] hipMemGetInfo: Returned hipSuccess :
memInfo.total: 12.06 GB
memInfo.free: 11.93 GB (99%)
docs/how_to_guides/debugging.md
-301
Просмотреть файл
@@ -1,301 +0,0 @@
# HIP Debugging
There are some techniques provided in HIP for developers to trace and debug codes during execution, this section describes some details and practical suggestions on debugging.
## Debugging tools
### Using ltrace
ltrace is a standard linux tool which provides a message to stderr on every dynamic library call.
Since ROCr and the ROCt (the ROC thunk, which is the thin user-space interface to the ROC kernel driver) are both dynamic libraries, this provides an easy way to trace the activity in these libraries.
Tracing can be a powerful way to quickly observe the flow of the application before diving into the details with a command-line debugger.
ltrace is a helpful tool to visualize the runtime behavior of the entire ROCm software stack.
The trace can also show performance issues related to accidental calls to expensive API calls on the critical path.
Here's a simple sample with command-line to trace hip APIs and output:
```console
$ ltrace -C -e "hip*" ./hipGetChanDesc
hipGetChanDesc->hipCreateChannelDesc(0x7ffdc4b66860, 32, 0, 0) = 0x7ffdc4b66860
hipGetChanDesc->hipMallocArray(0x7ffdc4b66840, 0x7ffdc4b66860, 8, 8) = 0
hipGetChanDesc->hipGetChannelDesc(0x7ffdc4b66848, 0xa63990, 5, 1) = 0
hipGetChanDesc->hipFreeArray(0xa63990, 0, 0x7f8c7fe13778, 0x7ffdc4b66848) = 0
PASSED!
+++ exited (status 0) +++
```
Another sample below with command-line only trace hsa APIs and output:
```console
$ ltrace -C -e "hsa*" ./hipGetChanDesc
libamdhip64.so.4->hsa_init(0, 0x7fff325a69d0, 0x9c80e0, 0 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtOpenKFD(0x7fff325a6590, 0x9c38c0, 0, 1) = 0
libhsa-runtime64.so.1->hsaKmtGetVersion(0x7fff325a6608, 0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtReleaseSystemProperties(3, 0x80084b01, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtAcquireSystemProperties(0x7fff325a6610, 0, 0, 1) = 0
libhsa-runtime64.so.1->hsaKmtGetNodeProperties(0, 0x7fff325a66a0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtGetNodeMemoryProperties(0, 1, 0x9c42b0, 0x936012) = 0
...
<... hsaKmtCreateEvent resumed> ) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 64, 0x7fff325a6690) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f1202749000, 4096, 0x7fff325a6690, 0) = 0
libhsa-runtime64.so.1->hsaKmtCreateEvent(0x7fff325a6700, 0, 0, 0x7fff325a66f0) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(1, 0x100000000, 576, 0x7fff325a67d8) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 8192, 64, 0x7fff325a6790) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f120273c000, 8192, 0x7fff325a6790, 0) = 0
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 4160, 0x7fff325a6450) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f120273a000, 4096, 0x7fff325a6450, 0) = 0
libhsa-runtime64.so.1->hsaKmtSetTrapHandler(1, 0x7f120273a000, 4096, 0x7f120273c000) = 0
<... hsa_init resumed> ) = 0
libamdhip64.so.4->hsa_system_get_major_extension_table(513, 1, 24, 0x7f1202597930) = 0
libamdhip64.so.4->hsa_iterate_agents(0x7f120171f050, 0, 0x7fff325a67f8, 0 <unfinished ...>
libamdhip64.so.4->hsa_agent_get_info(0x94f110, 17, 0x7fff325a67e8, 0) = 0
libamdhip64.so.4->hsa_amd_agent_iterate_memory_pools(0x94f110, 0x7f1201722816, 0x7fff325a67f0, 0x7f1201722816 <unfinished ...>
libamdhip64.so.4->hsa_amd_memory_pool_get_info(0x9c7fb0, 0, 0x7fff325a6744, 0x7fff325a67f0) = 0
libamdhip64.so.4->hsa_amd_memory_pool_get_info(0x9c7fb0, 1, 0x7fff325a6748, 0x7f1200d82df4) = 0
...
<... hsa_amd_agent_iterate_memory_pools resumed> ) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 17, 0x7fff325a67e8, 0) = 0
<... hsa_iterate_agents resumed> ) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 0, 0x7fff325a6850, 3) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 0xa000, 0x9e7cd8, 0) = 0
libamdhip64.so.4->hsa_agent_iterate_isas(0x9dbf30, 0x7f1201720411, 0x7fff325a6760, 0x7f1201720411) = 0
libamdhip64.so.4->hsa_isa_get_info_alt(0x94e7c8, 0, 0x7fff325a6728, 1) = 0
libamdhip64.so.4->hsa_isa_get_info_alt(0x94e7c8, 1, 0x9e7f90, 0) = 0
libamdhip64.so.4->hsa_agent_get_info(0x9dbf30, 4, 0x9e7ce8, 0) = 0
...
<... hsa_amd_memory_pool_allocate resumed> ) = 0
libamdhip64.so.4->hsa_ext_image_create(0x9dbf30, 0xa1c4c8, 0x7f10f2800000, 3 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtAllocMemory(0, 4096, 64, 0x7fff325a6740) = 0
libhsa-runtime64.so.1->hsaKmtQueryPointerInfo(0x7f1202736000, 0x7fff325a65e0, 0, 0) = 0
libhsa-runtime64.so.1->hsaKmtMapMemoryToGPUNodes(0x7f1202736000, 4096, 0x7fff325a66e8, 0) = 0
<... hsa_ext_image_create resumed> ) = 0
libamdhip64.so.4->hsa_ext_image_destroy(0x9dbf30, 0x7f1202736000, 0x9dbf30, 0 <unfinished ...>
libhsa-runtime64.so.1->hsaKmtUnmapMemoryToGPU(0x7f1202736000, 0x7f1202736000, 4096, 0x9c8050) = 0
libhsa-runtime64.so.1->hsaKmtFreeMemory(0x7f1202736000, 4096, 0, 0) = 0
<... hsa_ext_image_destroy resumed> ) = 0
libamdhip64.so.4->hsa_amd_memory_pool_free(0x7f10f2800000, 0x7f10f2800000, 256, 0x9e76f0) = 0
PASSED!
```
### Using ROCgdb
HIP developers on ROCm can use AMD's ROCgdb for debugging and profiling.
ROCgdb is the ROCm source-level debugger for Linux, based on GDB, the GNU source-level debugger, equivalent of cuda-gdb, can be used with debugger frontends, such as eclipse, vscode, or gdb-dashboard.
For details, see (https://github.com/ROCm/ROCgdb).
Below is a sample how to use ROCgdb run and debug HIP application, rocgdb is installed with ROCM package in the folder /opt/rocm/bin.
```console
$ export PATH=$PATH:/opt/rocm/bin
$ rocgdb ./hipTexObjPitch
GNU gdb (rocm-dkms-no-npi-hipclang-6549) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
For bug reporting instructions, please see:
<https://github.com/ROCm/ROCgdb/issues>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
...
Reading symbols from ./hipTexObjPitch...
(gdb) break main
Breakpoint 1 at 0x4013d1: file /home/<your_awesome_name>/hip-tests/samples/2_Cookbook/0_MatrixTranspose/MatrixTranspose.cpp, line 56.
(gdb) run
Starting program: MatrixTranspose
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main ()
at MatrixTranspose.cpp:56
56 int main() {
(gdb) c
```
### Other Debugging Tools
There are also other debugging tools available online developers can google and choose the one best suits the debugging requirements. For example, Microsoft Visual Studio and Windgb tools are options on Windows.
## Debugging HIP Applications
Below is an example on Linux to show how to get useful information from the debugger while running a simple hip application, which caused an issue of segmentation fault.
Simple HIP Program:
```cpp
#include <hip/hip_runtime.h>
#include <iostream>
#include <vector>
__global__ void kernel_add(int* a, int b) {
int i = threadIdx.x;
a[i] += b;
}
int main() {
constexpr size_t size = 1024;
int* ptr;
hipMalloc(&ptr, sizeof(int) * size);
hipMemset(ptr, 0, sizeof(int) * size);
std::vector<int> input(size, 0);
size_t i = 100;
std::for_each(input.begin(), input.end(), [&](int& a) { a = i; });
hipMemcpy(ptr, input.data(), sizeof(int) * size, hipMemcpyHostToDevice);
kernel_add<<<1, size>>>(ptr, 10);
std::vector<int> output = input;
hipMemcpy(output.data(), ptr, sizeof(int) * size, hipMemcpyDeviceToHost);
std::cout << ((std::all_of(output.begin(), output.end(), [&](int a) { return a == (i + 10); }))
? "passed"
: "failed")
<< std::endl;
hipFree(ptr);
}
```
Compile and run command:
```console
hipcc app.cpp -ggdb -o app
rocgdb ./app
```
```console
(gdb) b main
Breakpoint 1 at 0x21275e: file app.cpp, line 14.
(gdb) run
Starting program: /home/<your_awesome_name>/app
warning: os_agent_id 31475: `Device 1002:164e' architecture not supported.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, hipMalloc<int> (devPtr=0x7fffffffe098, size=4096) at /opt/rocm/include/hip/hip_runtime_api.h:8487
8487 return hipMalloc((void**)devPtr, size);
(gdb) bt
#0 hipMalloc<int> (devPtr=0x7fffffffe098, size=4096) at /opt/rocm/include/hip/hip_runtime_api.h:8487
#1 main () at app.cpp:14
(gdb) n
[New Thread 0x7fffeb7ff640 (LWP 1524879)]
[New Thread 0x7fffeaffe640 (LWP 1524880)]
[Thread 0x7fffeaffe640 (LWP 1524880) exited]
main () at app.cpp:15
15 hipMemset(ptr, 0, sizeof(int) * size);
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7e6ba80 (LWP 1524135) "app" main () at app.cpp:15
2 Thread 0x7fffeb7ff640 (LWP 1524879) "app" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
(gdb) thread 2
[Switching to thread 2 (Thread 0x7fffeb7ff640 (LWP 1524879))]
#0 __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
36 ../sysdeps/unix/sysv/linux/ioctl.c: No such file or directory.
(gdb) bt
#0 __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
#1 0x00007fffeb8fda80 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#2 0x00007fffeb8f6912 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#3 0x00007fffeb883021 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#4 0x00007fffeb85e026 in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#5 0x00007fffeb874b6a in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#6 0x00007fffeb828fdb in ?? () from /opt/rocm/lib/libhsa-runtime64.so.1
#7 0x00007ffff5c94b43 in start_thread (arg=<optimised out>) at ./nptl/pthread_create.c:442
#8 0x00007ffff5d26a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
...
```
A complete guide to `rocgdb` can be found [here](https://rocm.docs.amd.com/projects/ROCgdb/en/latest/).
On Windows, debugging HIP applications on IDE like Microsoft Visual Studio tools, are more informative and visible to debug codes, inspect variables, watch multiple details and examine the call stacks.
## Useful Environment Variables
HIP provides some environment variables which allow HIP, hip-clang, or HSA driver on Linux to disable some feature or optimization.
These are not intended for production but can be useful diagnose synchronization problems in the application (or driver).
Some of the most useful environment variables are described here. They are supported on the ROCm path on Linux and Windows as well.
### Kernel Enqueue Serialization
Developers can control kernel command serialization from the host using the environment variable,
AMD_SERIALIZE_KERNEL, for serializing kernel enqueue.
AMD_SERIALIZE_KERNEL = 1, Wait for completion before enqueue,
AMD_SERIALIZE_KERNEL = 2, Wait for completion after enqueue,
AMD_SERIALIZE_KERNEL = 3, Both.
Or
AMD_SERIALIZE_COPY, for serializing copies.
AMD_SERIALIZE_COPY = 1, Wait for completion before enqueue,
AMD_SERIALIZE_COPY = 2, Wait for completion after enqueue,
AMD_SERIALIZE_COPY = 3, Both.
So HIP runtime can wait for GPU idle before/after any GPU command depending on the environment setting.
### Making Device visible
For system with multiple devices, it's possible to make only certain device(s) visible to HIP via setting environment variable,
HIP_VISIBLE_DEVICES(or CUDA_VISIBLE_DEVICES on Nvidia platform), only devices whose index is present in the sequence are visible to HIP.
For example,
```console
$ HIP_VISIBLE_DEVICES=0,1
```
or in the application,
```cpp
if (totalDeviceNum > 2) {
setenv("HIP_VISIBLE_DEVICES", "0,1,2", 1);
assert(getDeviceNumber(false) == 3);
... ...
}
```
### Dump code object
Developers can dump code object to analyze compiler related issues via setting environment variable,
GPU_DUMP_CODE_OBJECT
### HSA related environment variables on Linux
On Linux with open source, HSA provides some environment variables help to analyze issues in driver or hardware, for example,
HSA_ENABLE_SDMA=0
It causes host-to-device and device-to-host copies to use compute shader blit kernels rather than the dedicated DMA copy engines.
Compute shader copies have low latency (typically < 5us) and can achieve approximately 80% of the bandwidth of the DMA copy engine.
This environment variable is useful to isolate issues with the hardware copy engines.
HSA_ENABLE_INTERRUPT=0
Causes completion signals to be detected with memory-based polling rather than interrupts.
This environment variable can be useful to diagnose interrupt storm issues in the driver.
### Summary of environment variables in HIP
The following is the summary of the most useful environment variables in HIP.
| **Environment variable** | **Default value** | **Usage** |
| ---------------------------------------------------------------------------------------------------------------| ----------------- | --------- |
| AMD_LOG_LEVEL <br><sub> Enable HIP log on different Level. </sub> | 0 | 0: Disable log. <br> 1: Enable log on error level. <br> 2: Enable log on warning and below levels. <br> 0x3: Enable log on information and below levels. <br> 0x4: Decode and display AQL packets. |
| AMD_LOG_MASK <br><sub> Enable HIP log on different Level. </sub> | 0x7FFFFFFF | 0x1: Log API calls. <br> 0x02: Kernel and Copy Commands and Barriers. <br> 0x4: Synchronization and waiting for commands to finish. <br> 0x8: Enable log on information and below levels. <br> 0x20: Queue commands and queue contents. <br> 0x40:Signal creation, allocation, pool. <br> 0x80: Locks and thread-safety code. <br> 0x100: Copy debug. <br> 0x200: Detailed copy debug. <br> 0x400: Resource allocation, performance-impacting events. <br> 0x800: Initialization and shutdown. <br> 0x1000: Misc debug, not yet classified. <br> 0x2000: Show raw bytes of AQL packet. <br> 0x4000: Show code creation debug. <br> 0x8000: More detailed command info, including barrier commands. <br> 0x10000: Log message location. <br> 0xFFFFFFFF: Log always even mask flag is zero. |
| HIP_VISIBLE_DEVICES(or CUDA_VISIBLE_DEVICES) <br><sub> Only devices whose index is present in the sequence are visible to HIP. </sub> | | 0,1,2: Depending on the number of devices on the system. |
| GPU_DUMP_CODE_OBJECT <br><sub> Dump code object. </sub> | 0 | 0: Disable. <br> 1: Enable. |
| AMD_SERIALIZE_KERNEL <br><sub> Serialize kernel enqueue. </sub> | 0 | 1: Wait for completion before enqueue. <br> 2: Wait for completion after enqueue. <br> 3: Both. |
| AMD_SERIALIZE_COPY <br><sub> Serialize copies. </sub> | 0 | 1: Wait for completion before enqueue. <br> 2: Wait for completion after enqueue. <br> 3: Both. |
| HIP_HOST_COHERENT <br><sub> Coherent memory in hipHostMalloc. </sub> | 0 | 0: memory is not coherent between host and GPU. <br> 1: memory is coherent with host. |
| AMD_DIRECT_DISPATCH <br><sub> Enable direct kernel dispatch (Currently for Linux, under development on Windows). </sub> | 1 | 0: Disable. <br> 1: Enable. |
| GPU_MAX_HW_QUEUES <br><sub> The maximum number of hardware queues allocated per device. </sub> | 4 | The variable controls how many independent hardware queues HIP runtime can create per process, per device. If application allocates more HIP streams than this number, then HIP runtime will reuse the same hardware queues for the new streams in round robin manner. Please note, this maximum number does not apply to either hardware queues that are created for CU masked HIP streams, or cooperative queue for HIP Cooperative Groups (there is only one single queue per device). |
| HIP_LAUNCH_BLOCKING <br><sub> Used for serialization on kernel execution. </sub> | 0 | 0: Disable. Kernel executes normally. <br> 1: Enable. Serializes kernel enqueue, behaves the same as AMD_SERIALIZE_KERNEL. |
## General Debugging Tips
- 'gdb --args' can be used to conveniently pass the executable and arguments to gdb.
- From inside GDB on Linux, you can set environment variables "set env". Note the command does not use an '=' sign:
```
(gdb) set env AMD_SERIALIZE_KERNEL 3
```
- The fault will be caught by the runtime but was actually generated by an asynchronous command running on the GPU. So, the GDB backtrace will show a path in the runtime.
- To determine the true location of the fault, force the kernels to execute synchronously by seeing the environment variables AMD_SERIALIZE_KERNEL=3 AMD_SERIALIZE_COPY=3. This will force HIP runtime to wait for the kernel to finish executing before retuning. If the fault occurs during the execution of a kernel, you can see the code which launched the kernel inside the backtrace. A bit of guesswork is required to determine which thread is actually causing the issue - typically it will the thread which is waiting inside the `libhsa-runtime64.so`.
- VM faults inside kernels can be caused by:
- incorrect code (ie a for loop which extends past array boundaries),
- memory issues - kernel arguments which are invalid (null pointers, unregistered host pointers, bad pointers),
- synchronization issues,
- compiler issues (incorrect code generation from the compiler),
- runtime issues.
docs/how_to_guides/install.md
-53
Просмотреть файл
@@ -1,53 +0,0 @@
# Installing HIP
HIP can be installed either on AMD ROCm platform with HIP-Clang compiler, or a CUDA platform with nvcc installed.
Note: The version definition for the HIP runtime is different from CUDA. Users can use hipRuntimeGerVersion function, on the AMD platform it returns the HIP runtime version, while on the NVIDIA platform, it returns the CUDA runtime version. There is no mapping or correlation between the HIP version and CUDA version.
## Prerequisites
On AMD platform, see Prerequisite Actions in ROCm_Installation_Guide (https://docs.amd.com/) for the release.
On NVIDIA platform, check system requirements in NVIDIA CUDA Installation Guide at https://docs.nvidia.com/cuda/cuda-installation-guide-linux/.
## AMD Platform
HIP is part of ROCM packages, it will be automatically installed following the ROCm Installation Guide on AMD public documentation site (https://docs.amd.com/) for the coresponding ROCm release.
By default, HIP is installed into /opt/rocm/hip.
## NVIDIA Platform
* Install Nvidia Driver
```
sudo apt-get install ubuntu-drivers-common && sudo ubuntu-drivers autoinstall
sudo reboot
```
Or download the latest cuda-toolkit at https://developer.nvidia.com/cuda-downloads
The driver will be installed automatically.
* Add the ROCm package server to your system as per the OS-specific guide in ROCm Installation Guide (https://docs.amd.com/) for the release.
* Install the "hip-runtime-nvidia" and "hip-dev" package. This will install CUDA SDK and the HIP porting layer.
```
apt-get install hip-runtime-nvidia hip-dev
```
* Default paths:
* By default HIP looks for CUDA SDK in /usr/local/cuda.
* By default HIP is installed into /opt/rocm/hip.
* Optionally, consider adding /opt/rocm/bin to your path to make it easier to use the tools.
# Verify your installation
Run hipconfig (instructions below assume default installation path):
```
/opt/rocm/bin/hipconfig --full
```
# How to build HIP from source
Developers can build HIP from source on either AMD or NVIDIA platforms, see
detailed instructions at [building HIP from source](../developer_guide/build.md).
docs/index.md
+50 -19
Просмотреть файл
@@ -1,4 +1,4 @@
# HIP Documentation
# HIP documentation
HIP is a C++ runtime API and kernel language that allows developers to create
portable applications for AMD and NVIDIA GPUs from single source code.
@@ -8,30 +8,61 @@ portable applications for AMD and NVIDIA GPUs from single source code.
::::{grid} 1 1 2 2
:gutter: 1
:::{grid-item-card} User Guide
- {doc}`/user_guide/programming_manual`
- {doc}`/user_guide/hip_rtc`
- {doc}`/user_guide/faq`
:::
:::{grid-item-card} Installation
* [Install HIP](./install/install)
* [Build HIP from source](./install/build)
:::{grid-item-card} How to Guides
- {doc}`/how_to_guides/install`
- {doc}`/how_to_guides/debugging`
:::
:::{grid-item-card} Reference
- {doc}`/doxygen/html/index`
- {doc}`/doxygen/html/modules`
- {doc}`/reference/kernel_language`
- {doc}`/reference/math_api`
- {doc}`/reference/terms`
- {doc}`/reference/deprecated_api_list`
* {doc}`/reference/programming_model`
* {doc}`/doxygen/html/index`
* [Deprecated APIs](./reference/deprecated_api_list)
:::
:::{grid-item-card} Developer Guide
- {doc}`/developer_guide/build`
- {doc}`/developer_guide/logging`
- {doc}`/developer_guide/contributing`
:::{grid-item-card} How-to
* [Debug with HIP](./how-to/debugging)
* [Generate logs](./how-to/logging)
:::
:::{grid-item-card} Conceptual
* {doc}`/understand/programming_model`
:::
::::
## Legacy documentation
These documents have not yet been ported over to the Diátaxis framework.
::::{grid} 1 1 2 2
:gutter: 1
:::{grid-item-card} Reference
* [C++ kernel language](./old/reference/kernel_language)
* [Table Comparing Syntax for Different Compute APIs](./old/reference/terms)
:::
:::{grid-item-card} User Guide
* [HIP Porting Guide](./old/user_guide/hip_porting_guide)
* [HIP Porting Driver API Guide](./old/user_guide/hip_porting_driver_api)
:::
::::
We welcome collaboration! If you’d like to contribute to our documentation, you can find instructions
on our {doc}`Contribute to ROCm docs <rocm:contribute/contributing>` page. Known issues are listed on
[GitHub](https://github.com/RadeonOpenCompute/ROCm/labels/Verified%20Issue).
If you want to contribute to the HIP project, refer to our [Contributor guidelines](./about/contributing).
docs/install/build.rst
+258
Просмотреть файл
@@ -0,0 +1,258 @@
*******************************************
Build HIP from source
*******************************************
.. _Building the HIP runtime:
Building the HIP runtime
==========================================================
Set the repository branch using the variable: ``ROCM_BRANCH``. For example, for ROCm 6.1, use:
.. code:: shell
export ROCM_BRANCH=rocm-6.1.x
.. tab-set::
.. tab-item:: AMD
:sync: amd
#. Get HIP source code.
.. note::
Starting in ROCM 5.6, CLR is a new repository that includes the former ROCclr, HIPAMD and
OpenCl repositories. OpenCL provides headers that ROCclr runtime depends on.
.. note::
Starting in ROCM 6.1, a new repository ``hipother`` is added to ROCm, which is branched out from HIP.
``hipother`` provides files required to support the HIP back-end implementation on some non-AMD platforms,
like NVIDIA.
.. code:: shell
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/clr.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hip.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hipother.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/HIPCC.git
CLR (Common Language Runtime) or ROCclr is a virtual device interface that various AMD runtimes interact with.
HIPAMD provides implementation specifically for HIP on te AMD platform.
OpenCL provides headers that ROCclr runtime currently depends on.
hipother provides headers and implementation specifically for non-AMD HIP platforms, like NVIDIA.
#. Set the environment variables.
.. code:: shell
export CLR_DIR="$(readlink -f clr)"
export HIP_DIR="$(readlink -f hip)"
export HIP_OTHER="$(readlink -f hipother)"
export HIPCC_DIR="$(readlink -f HIPCC)"
#. Build the HIPCC runtime.
.. code:: shell
cd "$HIPCC_DIR"
mkdir -p build; cd build
cmake ..
make -j4
#. Build HIP.
.. code:: shell
cd "$CLR_DIR"
mkdir -p build; cd build
cmake -DHIP_COMMON_DIR=$HIP_DIR -DHIP_PLATFORM=amd -DCMAKE_PREFIX_PATH="/opt/rocm/" -DCMAKE_INSTALL_PREFIX=$PWD/install -DHIPCC_BIN_DIR=$HIPCC_DIR/build -DHIP_CATCH_TEST=0 -DCLR_BUILD_HIP=ON -DCLR_BUILD_OCL=OFF ..
make -j$(nproc)
sudo make install
.. note::
Note, if you don't specify ``CMAKE_INSTALL_PREFIX``, the HIP runtime is installed at
``<ROCM_PATH>/hip``. The default version of HIP is the latest release.
Default paths and environment variables:
* HIP is installed into ``<ROCM_PATH>/hip``. This can be overridden by setting the ``HIP_PATH``
environment variable.
* HSA is in ``<ROCM_PATH>/hsa``. This can be overridden by setting the ``HSA_PATH``
environment variable.
* Clang is in ``<ROCM_PATH>/llvm/bin``. This can be overridden by setting the
``HIP_CLANG_PATH`` environment variable.
* The device library is in ``<ROCM_PATH>/lib``. This can be overridden by setting the
``DEVICE_LIB_PATH`` environment variable.
* Optionally, you can add ``<ROCM_PATH>/bin`` to your ``PATH``, which can make it easier to
use the tools.
* Optionally, you can set ``HIPCC_VERBOSE=7`` to output the command line for compilation.
After you run the ``make install`` command, make sure ``HIP_PATH`` points to ``$PWD/install/hip``.
#. Generate a profiling header after adding/changing a HIP API.
When you add or change a HIP API, you may need to generate a new ``hip_prof_str.h`` header.
This header is used by ROCm tools to track HIP APIs, such as``rocprofiler`` and ``roctracer``.
To generate the header after your change, use the ``hip_prof_gen.py`` tool located in
``hipamd/src``.
Usage:
.. code:: shell
`hip_prof_gen.py [-v] <input HIP API .h file> <patched srcs path> <previous output> [<output>]`
Flags:
* ``-v``: Verbose messages
* ``-r``: Process source directory recursively
* ``-t``: API types matching check
* ``--priv``: Private API check
* ``-e``: On error exit mode
* ``-p``: ``HIP_INIT_API`` macro patching mode
Example usage:
.. code:: shell
hip_prof_gen.py -v -p -t --priv <hip>/include/hip/hip_runtime_api.h \
<hipamd>/src <hipamd>/include/hip/amd_detail/hip_prof_str.h \
<hipamd>/include/hip/amd_detail/hip_prof_str.h.new
.. tab-item:: NVIDIA
:sync: nvidia
#. Get the HIP source code.
.. code:: shell
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/clr.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hip.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hipother.git
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/HIPCC.git
#. Set the environment variables.
.. code:: shell
export CLR_DIR="$(readlink -f clr)"
export HIP_DIR="$(readlink -f hip)"
export HIP_OTHER="$(readlink -f hipother)"
export HIPCC_DIR="$(readlink -f HIPCC)"
#. Build the HIPCC runtime.
.. code:: shell
cd "$HIPCC_DIR"
mkdir -p build; cd build
cmake ..
make -j4
#. Build HIP.
.. code:: shell
cd "$CLR_DIR"
mkdir -p build; cd build
cmake -DHIP_COMMON_DIR=$HIP_DIR -DHIP_PLATFORM=nvidia -DCMAKE_INSTALL_PREFIX=$PWD/install -DHIPCC_BIN_DIR=$HIPCC_DIR/build -DHIP_CATCH_TEST=0 -DCLR_BUILD_HIP=ON -DCLR_BUILD_OCL=OFF ..
make -j$(nproc)
sudo make install
Build HIP tests
=================================================
.. tab-set::
.. tab-item:: AMD
:sync: amd
* Build HIP directed tests.
.. code:: shell
sudo make install
make -j$(nproc) build_tests
By default, all HIP directed tests are built and generated in
``$CLR_DIR/build/hipamd/directed_tests``.
* Run all HIP ``directed_tests``.
.. code:: shell
ctest
or
.. code:: shell
make test
* Build and run a single directed test.
.. code:: shell
make directed_tests.texture.hipTexObjPitch
cd $CLR_DIR/build/hipamd/directed_tests/texture
./hipTexObjPitch
.. note::
The integrated HIP directed tests will be deprecated in a future release.
* Build HIP catch tests.
HIP catch tests are separate from the HIP project and use Catch2.
* Get HIP tests source code.
.. code:: shell
git clone -b "$ROCM_BRANCH" https://github.com/ROCm/hip-tests.git
* Build HIP tests from source.
.. code:: shell
export HIPTESTS_DIR="$(readlink -f hip-tests)"
cd "$HIPTESTS_DIR"
mkdir -p build; cd build
export HIP_PATH=$CLR_DIR/build/install # or any path where HIP is installed; for example: ``/opt/rocm``
cmake ../catch/ -DHIP_PLATFORM=amd
make -j$(nproc) build_tests
ctest # run tests
HIP catch tests are built in ``$HIPTESTS_DIR/build``.
To run any single catch test, use this example:
.. code:: shell
cd $HIPTESTS_DIR/build/catch_tests/unit/texture
./TextureTest
* Build a HIP Catch2 standalone test.
.. code:: shell
cd "$HIPTESTS_DIR"
hipcc $HIPTESTS_DIR/catch/unit/memory/hipPointerGetAttributes.cc \
-I ./catch/include ./catch/hipTestMain/standalone_main.cc \
-I ./catch/external/Catch2 -o hipPointerGetAttributes
./hipPointerGetAttributes
...
All tests passed
.. tab-item:: NVIDIA
:sync: nvidia
The commands to build HIP tests on an NVIDIA platform are the same as on an AMD platform.
However, you must first set ``-DHIP_PLATFORM=nvidia``.
* Run HIP. Compile and run the
`square sample <https://github.com/ROCm-Developer-Tools/hip-tests/tree/rocm-5.5.x/samples/0_Intro/square>`_.
docs/install/install.rst
+79
Просмотреть файл
@@ -0,0 +1,79 @@
*******************************************
Install HIP
*******************************************
HIP can be installed on AMD (ROCm with HIP-Clang) and NVIDIA (CUDA with nvcc) platforms.
Note: The version definition for the HIP runtime is different from CUDA. On an AMD platform, the
``hipRuntimeGerVersion`` function returns the HIP runtime version; on an NVIDIA platform, this function
returns the CUDA runtime version.
Prerequisites
=======================================
.. tab-set::
.. tab-item:: AMD
:sync: amd
Refer to the Prerequisites section in the ROCm install guides:
* :doc:`rocm-install-on-linux:reference/system-requirements`
* :doc:`rocm-install-on-windows:reference/system-requirements`
.. tab-item:: NVIDIA
:sync: nvidia
Check the system requirements in the
`NVIDIA CUDA Installation Guide <https://docs.nvidia.com/cuda/cuda-installation-guide-linux/>`_.
Installation
=======================================
.. tab-set::
.. tab-item:: AMD
:sync: amd
HIP is automatically installed during the ROCm installation. If you haven't yet installed ROCm, you
can find installation instructions here:
* :doc:`rocm-install-on-linux:reference/system-requirements`
* :doc:`rocm-install-on-windows:reference/system-requirements`
By default, HIP is installed into ``/opt/rocm/hip``.
.. tab-item:: NVIDIA
:sync: nvidia
#. Install the NVIDIA driver.
.. code:: shell
sudo apt-get install ubuntu-drivers-common && sudo ubuntu-drivers autoinstall
sudo reboot
Alternatively, you can download the latest
`CUDA Toolkit <https://developer.nvidia.com/cuda-downloads>`_.
#. Install the ``hip-runtime-nvidia`` and ``hip-dev`` packages. This installs the CUDA SDK and HIP
porting layer.
.. code:: shell
apt-get install hip-runtime-nvidia hip-dev
The default paths are:
* CUDA SDK: ``/usr/local/cuda``
* HIP: ``/opt/rocm/hip``
You can optionally add ``/opt/rocm/bin`` to your path, which can make it easier to use the tools.
Verify your installation
==========================================================
Run ``hipconfig`` in your installation path.
.. code:: shell
/opt/rocm/bin/hipconfig --full
docs/reference/glossary.md → docs/old/glossary.md
+4 -4
Просмотреть файл
@@ -8,13 +8,13 @@ The default device can be set with hipSetDevice.
- "active host thread" - the thread which is running the HIP APIs.
- HIP-Clang - Heterogeneous AMDGPU Compiler, with its capability to compile HIP programs on AMD platform (https://github.com/ROCm/llvm-project).
- HIP-Clang - Heterogeneous AMDGPU Compiler, with its capability to compile HIP programs on AMD platform (https://github.com/RadeonOpenCompute/llvm-project).
- clr - a repository for AMD Common Language Runtime, contains source codes for AMD's compute languages runtimes: HIP and OpenCL™.
- clr - a repository for AMD Common Language Runtime, contains source codes for AMD's compute languages runtimes: HIP and OpenCL�.
clr (https://github.com/ROCm/clr) contains the following three parts,
hipamd: contains implementation of HIP language on AMD platform.
rocclr: contains common runtime used in HIP and OpenCL™, which provides virtual device interfaces that compute runtimes interact with different backends such as ROCr on Linux or PAL on Windows.
opencl: contains implementation of OpenCL™ on AMD platform.
rocclr: contains common runtime used in HIP and OpenCL�, which provides virtual device interfaces that compute runtimes interact with different backends such as ROCr on Linux or PAL on Windows.
opencl: contains implementation of OpenCL� on AMD platform.
- hipify tools - tools to convert CUDA code to portable C++ code (https://github.com/ROCm/HIPIFY).
docs/old/reference/kernel_language.rst
+1123
Просмотреть файл
Разница между файлами не показана из-за своего большого размера Загрузить разницу
docs/reference/terms.md → docs/old/reference/terms.md
Просмотреть файл
docs/user_guide/faq.md → docs/old/user_guide/faq.md
+6 -6
Просмотреть файл
@@ -70,11 +70,11 @@ HIP includes growing support for the four key math libraries using hipBlas, hipF
These offer pointer-based memory interfaces (as opposed to opaque buffers) and can be easily interfaced with other HIP applications.
The hip interfaces support both ROCm and CUDA paths, with familiar library interfaces.
- [hipBlas](https://github.com/ROCm/hipBLAS), which utilizes [rocBlas](https://github.com/ROCm/rocBLAS).
- [hipFFt](https://github.com/ROCm/hipfft)
- [hipsSPARSE](https://github.com/ROCm/hipsparse)
- [hipRAND](https://github.com/ROCm/hipRAND)
- [MIOpen](https://github.com/ROCm/MIOpen)
- [hipBlas](https://github.com/ROCmSoftwarePlatform/hipBLAS), which utilizes [rocBlas](https://github.com/ROCmSoftwarePlatform/rocBLAS).
- [hipFFt](https://github.com/ROCmSoftwarePlatform/hipfft)
- [hipsSPARSE](https://github.com/ROCmSoftwarePlatform/hipsparse)
- [hipRAND](https://github.com/ROCmSoftwarePlatform/hipRAND)
- [MIOpen](https://github.com/ROCmSoftwarePlatform/MIOpen)
Additionally, some of the cublas routines are automatically converted to hipblas equivalents by the HIPIFY tools. These APIs use cublas or hcblas depending on the platform and replace the need to use conditional compilation.
@@ -101,7 +101,7 @@ As a result, the OpenCL syntax is different from CUDA, and the porting tools hav
The tools also struggle with more complex CUDA applications, in particular, those that use templates, classes, or other C++ features inside the kernel.
## What hardware does HIP support?
- For AMD platforms, see the [ROCm documentation](https://github.com/ROCm/ROCm#supported-gpus) for the list of supported platforms.
- For AMD platforms, see the [ROCm documentation](https://github.com/RadeonOpenCompute/ROCm#supported-gpus) for the list of supported platforms.
- For Nvidia platforms, HIP requires Unified Memory and should run on any device supporting CUDA SDK 6.0 or newer. We have tested the Nvidia Titan and Tesla K40.
## Do HIPIFY tools automatically convert all source code?
docs/user_guide/hip_porting_driver_api.md → docs/old/user_guide/hip_porting_driver_api.md
Просмотреть файл
docs/user_guide/hip_porting_guide.md → docs/old/user_guide/hip_porting_guide.md
+20 -13
Просмотреть файл
@@ -78,19 +78,26 @@ directory names.
### Library Equivalents
| CUDA Library | ROCm Library | Comment |
|------- | --------- | ----- |
| cuBLAS | rocBLAS | Basic Linear Algebra Subroutines
| cuFFT | rocFFT | Fast Fourier Transfer Library
| cuSPARSE | rocSPARSE | Sparse BLAS + SPMV
| cuSolver | rocSOLVER | Lapack library
| AMG-X | rocALUTION | Sparse iterative solvers and preconditioners with Geometric and Algebraic MultiGrid
| Thrust | rocThrust | C++ parallel algorithms library
| CUB | rocPRIM | Low Level Optimized Parallel Primitives
| cuDNN | MIOpen | Deep learning Solver Library
| cuRAND | rocRAND | Random Number Generator Library
| EIGEN | EIGEN - HIP port | C++ template library for linear algebra: matrices, vectors, numerical solvers,
| NCCL | RCCL | Communications Primitives Library based on the MPI equivalents
Most CUDA libraries have a corresponding ROCm library with similar functionality and APIs. However, ROCm also provides HIP marshalling libraries that greatly simplify the porting process because they more precisely reflect their CUDA counterparts and can be used with either the AMD or NVIDIA platforms (see "Identifying HIP Target Platform" below). There are a few notable exceptions:
- MIOpen does not have a marshalling library interface to ease porting from cuDNN.
- RCCL is a drop-in replacement for NCCL and implements the NCCL APIs.
- hipBLASLt does not have a ROCm library but can still target the NVIDIA platform, as needed.
- EIGEN's HIP support is part of the library.
| CUDA Library | HIP Library | ROCm Library | Comment |
|------------- | ----------- | ------------ | ------- |
| cuBLAS | hipBLAS | rocBLAS | Basic Linear Algebra Subroutines
| cuBLASLt | hipBLASLt | N/A | Basic Linear Algebra Subroutines, lightweight and new flexible API
| cuFFT | hipFFT | rocFFT | Fast Fourier Transfer Library
| cuSPARSE | hipSPARSE | rocSPARSE | Sparse BLAS + SPMV
| cuSolver | hipSOLVER | rocSOLVER | Lapack library
| AMG-X | N/A | rocALUTION | Sparse iterative solvers and preconditioners with Geometric and Algebraic MultiGrid
| Thrust | N/A | rocThrust | C++ parallel algorithms library
| CUB | hipCUB | rocPRIM | Low Level Optimized Parallel Primitives
| cuDNN | N/A | MIOpen | Deep learning Solver Library
| cuRAND | hipRAND | rocRAND | Random Number Generator Library
| EIGEN | EIGEN | N/A | C++ template library for linear algebra: matrices, vectors, numerical solvers,
| NCCL | N/A | RCCL | Communications Primitives Library based on the MPI equivalents
docs/user_guide/hip_rtc.md → docs/old/user_guide/hip_rtc.md
Просмотреть файл
docs/user_guide/programming_manual.md → docs/old/user_guide/programming_manual.md
Просмотреть файл
docs/reference/deprecated_api_list.md
-90
Просмотреть файл
@@ -1,90 +0,0 @@
# HIP Deprecated Runtime Functions
## HIP Context Management APIs
CUDA supports cuCtx API, the Driver API that defines "Context" and "Devices" as separate entities. Contexts contain a single device, and a device can theoretically have multiple contexts. HIP initially added limited support for these API to facilitate easy porting from existing driver codes. These API are marked as deprecated now since there are better alternate interface (such as hipSetDevice or the stream API) to achieve the required functions.
### hipCtxCreate
### hipCtxDestroy
### hipCtxPopCurrent
### hipCtxPushCurrent
### hipCtxSetCurrent
### hipCtxGetCurrent
### hipCtxGetDevice
### hipCtxGetApiVersion
### hipCtxGetCacheConfig
### hipCtxSetCacheConfig
### hipCtxSetSharedMemConfig
### hipCtxGetSharedMemConfig
### hipCtxSynchronize
### hipCtxGetFlags
### hipCtxEnablePeerAccess
### hipCtxDisablePeerAccess
### hipDevicePrimaryCtxGetState
### hipDevicePrimaryCtxRelease
### hipDevicePrimaryCtxRetain
### hipDevicePrimaryCtxReset
### hipDevicePrimaryCtxSetFlags
## HIP Memory Management APIs
### hipMallocHost
Should use "hipHostMalloc" instead.
### hipMemAllocHost
Should use "hipHostMalloc" instead.
### hipHostAlloc
Should use "hipHostMalloc" instead.
### hipFreeHost
Should use "hipHostFree" instead.
### hipMemcpyToArray
### hipMemcpyFromArray
## HIP Profiler Control APIs
### hipProfilerStart
Should use roctracer/rocTX instead
### hipProfilerStop
Should use roctracer/rocTX instead
## HIP Texture Management APIs
### hipGetTextureReference
### hipGetTextureAlignmentOffset
### hipTexRefSetAddressMode
### hipTexRefSetArray
### hipTexRefSetFilterMode
### hipTexRefSetFlags
### hipTexRefSetFormat
### hipTexRefGetAddress
### hipTexRefGetAddressMode
### hipTexRefGetFilterMode
### hipTexRefGetFlags
### hipTexRefGetFormat
### hipTexRefGetMaxAnisotropy
### hipTexRefGetMipmapFilterMode
### hipTexRefGetMipmapLevelBias
### hipTexRefGetMipmapLevelClamp
### hipTexRefGetMipMappedArray
### hipTexRefSetAddress
### hipTexRefSetAddress2D
### hipTexRefSetMaxAnisotropy
### hipTexRefSetBorderColor
### hipTexRefSetMipmapFilterMode
### hipTexRefSetMipmapLevelBias
### hipTexRefSetMipmapLevelClamp
### hipTexRefSetMipmappedArray
### hipTexRefGetBorderColor
### hipTexRefGetArray
### hipBindTexture
### hipBindTexture2D
### hipBindTextureToArray
### hipUnbindTexture
### hipBindTextureToMipmappedArray
docs/reference/deprecated_api_list.rst
+94
Просмотреть файл
@@ -0,0 +1,94 @@
.. meta::
:description: HIP deprecated runtime API functions.
:keywords: AMD, ROCm, HIP, deprecated, API
**********************************************************************************************
HIP deprecated runtime API functions
**********************************************************************************************
Several of our API functions have been flagged for deprecation. Using the following functions results in
errors and unexpected results, so we encourage you to update your code accordingly.
Context management
============================================================
CUDA supports cuCtx API, which is the driver API that defines "Context" and "Devices" as separate
entities. Context contains a single device, and a device can theoretically have multiple contexts. HIP
initially added limited support for these APIs in order to facilitate porting from existing driver codes.
These APIs are now marked as deprecated because there are better alternate interfaces (such as
``hipSetDevice`` or the stream API) to achieve these functions.
* ``hipCtxCreate``
* ``hipCtxDestroy``
* ``hipCtxPopCurrent``
* ``hipCtxPushCurrent``
* ``hipCtxSetCurrent``
* ``hipCtxGetCurrent``
* ``hipCtxGetDevice``
* ``hipCtxGetApiVersion``
* ``hipCtxGetCacheConfig``
* ``hipCtxSetCacheConfig``
* ``hipCtxSetSharedMemConfig``
* ``hipCtxGetSharedMemConfig``
* ``hipCtxSynchronize``
* ``hipCtxGetFlags``
* ``hipCtxEnablePeerAccess``
* ``hipCtxDisablePeerAccess``
* ``hipDevicePrimaryCtxGetState``
* ``hipDevicePrimaryCtxRelease``
* ``hipDevicePrimaryCtxRetain``
* ``hipDevicePrimaryCtxReset``
* ``hipDevicePrimaryCtxSetFlags``
Memory management
============================================================
* ``hipMallocHost`` (replaced with ``hipHostMalloc``)
* ``hipMemAllocHost`` (replaced with ``hipHostMalloc``)
* ``hipHostAlloc`` (replaced with ``hipHostMalloc``)
* ``hipFreeHost`` (replaced with ``hipHostFree``)
* ``hipMemcpyToArray``
* ``hipMemcpyFromArray``
Profiler control
============================================================
* ``hipProfilerStart`` (use roctracer/rocTX)
* ``hipProfilerStop`` (use roctracer/rocTX)
Texture management
============================================================
* ``hipGetTextureReference``
* ``hipTexRefSetAddressMode``
* ``hipTexRefSetArray``
* ``hipTexRefSetFilterMode``
* ``hipTexRefSetFlags``
* ``hipTexRefSetFormat``
* ``hipTexRefGetAddress``
* ``hipTexRefGetAddressMode``
* ``hipTexRefGetFilterMode``
* ``hipTexRefGetFlags``
* ``hipTexRefGetFormat``
* ``hipTexRefGetMaxAnisotropy``
* ``hipTexRefGetMipmapFilterMode``
* ``hipTexRefGetMipmapLevelBias``
* ``hipTexRefGetMipmapLevelClamp``
* ``hipTexRefGetMipMappedArray``
* ``hipTexRefSetAddress``
* ``hipTexRefSetAddress2D``
* ``hipTexRefSetMaxAnisotropy``
* ``hipTexRefSetBorderColor``
* ``hipTexRefSetMipmapFilterMode``
* ``hipTexRefSetMipmapLevelBias``
* ``hipTexRefSetMipmapLevelClamp``
* ``hipTexRefSetMipmappedArray``
* ``hipTexRefGetBorderColor``
* ``hipTexRefGetArray``
* ``hipBindTexture``
* ``hipBindTexture2D``
* ``hipBindTextureToArray``
* ``hipGetTextureAlignmentOffset``
* ``hipUnbindTexture``
* ``hipBindTextureToMipmappedArray``
docs/reference/kernel_language.md
-911
Просмотреть файл
@@ -1,911 +0,0 @@
# Kernel Language Syntax
HIP provides a C++ syntax that is suitable for compiling most code that commonly appears in compute kernels, including classes, namespaces, operator overloading, templates and more. Additionally, it defines other language features designed specifically to target accelerators, such as the following:
- A kernel-launch syntax that uses standard C++, resembles a function call and is portable to all HIP targets
- Short-vector headers that can serve on a host or a device
- Math functions resembling those in the "math.h" header included with standard C++ compilers
- Built-in functions for accessing specific GPU hardware capabilities
This section describes the built-in variables and functions accessible from the HIP kernel. It is intended for readers familiar with CUDA kernel syntax and wanting to understand how HIP is different from CUDA.
Features are marked with one of the following keywords:
- **Supported**---HIP supports the feature with a Cuda-equivalent function
- **Not supported**---HIP does not support the feature
- **Under development**---the feature is under development but not yet available
## Function-Type Qualifiers
### `__device__`
Supported `__device__` functions are
- Executed on the device
- Called from the device only
The `__device__` keyword can combine with the host keyword (see {ref}`host_attr`).
### `__global__`
Supported `__global__` functions are
- Executed on the device
- Called ("launched") from the host
HIP `__global__` functions must have a `void` return type, and the first parameter to a HIP `__global__` function must have the type `hipLaunchParm`. See [Kernel-Launch Example](#kernel-launch-example).
HIP lacks dynamic-parallelism support, so `__global__ ` functions cannot be called from the device.
### `__host__`
Supported `__host__` functions are
- Executed on the host
- Called from the host
`__host__` can combine with `__device__`, in which case the function compiles for both the host and device. These functions cannot use the HIP grid coordinate functions (for example, "threadIdx.x"). A possible workaround is to pass the necessary coordinate info as an argument to the function.
`__host__` cannot combine with `__global__`.
HIP parses the `__noinline__` and `__forceinline__` keywords and converts them to the appropriate Clang attributes.
## Calling `__global__` Functions
`__global__` functions are often referred to as *kernels,* and calling one is termed *launching the kernel.* These functions require the caller to specify an "execution configuration" that includes the grid and block dimensions. The execution configuration can also include other information for the launch, such as the amount of additional shared memory to allocate and the stream where the kernel should execute. HIP introduces a standard C++ calling convention to pass the execution configuration to the kernel in addition to the Cuda <<< >>> syntax. In HIP,
- Kernels launch with either <<< >>> syntax or the "hipLaunchKernelGGL" function
- The first five parameters to hipLaunchKernelGGL are the following:
- **symbol kernelName**: the name of the kernel to launch. To support template kernels which contains "," use the HIP_KERNEL_NAME macro. The hipify tools insert this automatically.
- **dim3 gridDim**: 3D-grid dimensions specifying the number of blocks to launch.
- **dim3 blockDim**: 3D-block dimensions specifying the number of threads in each block.
- **size_t dynamicShared**: amount of additional shared memory to allocate when launching the kernel (see [__shared__](#__shared__))
- **hipStream_t**: stream where the kernel should execute. A value of 0 corresponds to the NULL stream (see [Synchronization Functions](#synchronization-functions)).
- Kernel arguments follow these first five parameters
```
// Example pseudo code introducing hipLaunchKernelGGL:
__global__ MyKernel(hipLaunchParm lp, float *A, float *B, float *C, size_t N)
{
...
}
MyKernel<<<dim3(gridDim), dim3(groupDim), 0, 0>>> (a,b,c,n);
// Alternatively, kernel can be launched by
// hipLaunchKernelGGL(MyKernel, dim3(gridDim), dim3(groupDim), 0/*dynamicShared*/, 0/*stream), a, b, c, n);
```
The hipLaunchKernelGGL macro always starts with the five parameters specified above, followed by the kernel arguments. HIPIFY tools optionally convert Cuda launch syntax to hipLaunchKernelGGL, including conversion of optional arguments in <<< >>> to the five required hipLaunchKernelGGL parameters. The dim3 constructor accepts zero to three arguments and will by default initialize unspecified dimensions to 1. See [dim3](#dim3). The kernel uses the coordinate built-ins (thread*, block*, grid*) to determine coordinate index and coordinate bounds of the work item that's currently executing. See [Coordinate Built-Ins](#coordinate-built-ins).
Please note, HIP does not support kernel launch with total work items defined in dimension with size gridDim x blockDim >= 2^32.
## Kernel-Launch Example
```
// Example showing device function, __device__ __host__
// <- compile for both device and host
float PlusOne(float x)
{
return x + 1.0;
}
__global__
void
MyKernel (hipLaunchParm lp, /*lp parm for execution configuration */
const float *a, const float *b, float *c, unsigned N)
{
unsigned gid = threadIdx.x; // <- coordinate index function
if (gid < N) {
c[gid] = a[gid] + PlusOne(b[gid]);
}
}
void callMyKernel()
{
float *a, *b, *c; // initialization not shown...
unsigned N = 1000000;
const unsigned blockSize = 256;
MyKernel<<<dim3(gridDim), dim3(groupDim), 0, 0>>> (a,b,c,n);
// Alternatively, kernel can be launched by
// hipLaunchKernelGGL(MyKernel, dim3(N/blockSize), dim3(blockSize), 0, 0, a,b,c,N);
}
```
## Variable-Type Qualifiers
### `__constant__`
The `__constant__` keyword is supported. The host writes constant memory before launching the kernel; from the GPU, this memory is read-only during kernel execution. The functions for accessing constant memory (hipGetSymbolAddress(), hipGetSymbolSize(), hipMemcpyToSymbol(), hipMemcpyToSymbolAsync(), hipMemcpyFromSymbol(), hipMemcpyFromSymbolAsync()) are available.
### `__shared__`
The `__shared__` keyword is supported.
`extern __shared__` allows the host to dynamically allocate shared memory and is specified as a launch parameter.
Previously, it was essential to declare dynamic shared memory using the HIP_DYNAMIC_SHARED macro for accuracy, as using static shared memory in the same kernel could result in overlapping memory ranges and data-races.
Now, the HIP-Clang compiler provides support for extern shared declarations, and the HIP_DYNAMIC_SHARED option is no longer required..
### `__managed__`
Managed memory, including the `__managed__` keyword, are supported in HIP combined host/device compilation.
### `__restrict__`
The `__restrict__` keyword tells the compiler that the associated memory pointer will not alias with any other pointer in the kernel or function. This feature can help the compiler generate better code. In most cases, all pointer arguments must use this keyword to realize the benefit.
## Built-In Variables
### Coordinate Built-Ins
Built-ins determine the coordinate of the active work item in the execution grid. They are defined in amd_hip_runtime.h (rather than being implicitly defined by the compiler).
In HIP, built-ins coordinate variable definitions are the same as in Cuda, for instance:
threadIdx.x, blockIdx.y, gridDim.y, etc.
The products gridDim.x * blockDim.x, gridDim.y * blockDim.y and gridDim.z * blockDim.z are always less than 2^32.
Coordinates builtins are implemented as structures for better performance. When used with printf, they needs to be casted to integer types explicitly.
### warpSize
The warpSize variable is of type int and contains the warp size (in threads) for the target device. Note that all current Nvidia devices return 32 for this variable, and current AMD devices return 64 for gfx9 and 32 for gfx10 and above. The warpSize variable should only be used in device functions. Device code should use the warpSize built-in to develop portable wave-aware code.
## Vector Types
Note that these types are defined in hip_runtime.h and are not automatically provided by the compiler.
### Short Vector Types
Short vector types derive from the basic integer and floating-point types. They are structures defined in hip_vector_types.h. The first, second, third and fourth components of the vector are accessible through the ```x```, ```y```, ```z``` and ```w``` fields, respectively. All the short vector types support a constructor function of the form ```make_<type_name>()```. For example, ```float4 make_float4(float x, float y, float z, float w)``` creates a vector of type ```float4``` and value ```(x,y,z,w)```.
HIP supports the following short vector formats:
- Signed Integers:
- char1, char2, char3, char4
- short1, short2, short3, short4
- int1, int2, int3, int4
- long1, long2, long3, long4
- longlong1, longlong2, longlong3, longlong4
- Unsigned Integers:
- uchar1, uchar2, uchar3, uchar4
- ushort1, ushort2, ushort3, ushort4
- uint1, uint2, uint3, uint4
- ulong1, ulong2, ulong3, ulong4
- ulonglong1, ulonglong2, ulonglong3, ulonglong4
- Floating Points
- float1, float2, float3, float4
- double1, double2, double3, double4
### dim3
dim3 is a three-dimensional integer vector type commonly used to specify grid and group dimensions. Unspecified dimensions are initialized to 1.
```
typedef struct dim3 {
uint32_t x;
uint32_t y;
uint32_t z;
dim3(uint32_t _x=1, uint32_t _y=1, uint32_t _z=1) : x(_x), y(_y), z(_z) {};
};
```
## Memory-Fence Instructions
HIP supports __threadfence() and __threadfence_block().
HIP provides workaround for threadfence_system() under the HIP-Clang path.
To enable the workaround, HIP should be built with environment variable HIP_COHERENT_HOST_ALLOC enabled.
In addition,the kernels that use __threadfence_system() should be modified as follows:
- The kernel should only operate on finegrained system memory; which should be allocated with hipHostMalloc().
- Remove all memcpy for those allocated finegrained system memory regions.
## Synchronization Functions
The __syncthreads() built-in function is supported in HIP. The __syncthreads_count(int), __syncthreads_and(int) and __syncthreads_or(int) functions are under development.
## Math Functions
HIP-Clang supports a set of math operations callable from the device.
### Single Precision Mathematical Functions
Following is the list of supported single precision mathematical functions.
| **Function** | **Supported on Host** | **Supported on Device** |
| --- | --- | --- |
| float acosf ( float x ) <br><sub>Calculate the arc cosine of the input argument.</sub> | ✓ | ✓ |
| float acoshf ( float x ) <br><sub>Calculate the nonnegative arc hyperbolic cosine of the input argument.</sub> | ✓ | ✓ |
| float asinf ( float x ) <br><sub>Calculate the arc sine of the input argument.</sub> | ✓ | ✓ |
| float asinhf ( float x ) <br><sub>Calculate the arc hyperbolic sine of the input argument.</sub> | ✓ | ✓ |
| float atan2f ( float y, float x ) <br><sub>Calculate the arc tangent of the ratio of first and second input arguments.</sub> | ✓ | ✓ |
| float atanf ( float x ) <br><sub>Calculate the arc tangent of the input argument.</sub> | ✓ | ✓ |
| float atanhf ( float x ) <br><sub>Calculate the arc hyperbolic tangent of the input argument.</sub> | ✓ | ✓ |
| float cbrtf ( float x ) <br><sub>Calculate the cube root of the input argument.</sub> | ✓ | ✓ |
| float ceilf ( float x ) <br><sub>Calculate ceiling of the input argument.</sub> | ✓ | ✓ |
| float copysignf ( float x, float y ) <br><sub>Create value with given magnitude, copying sign of second value.</sub> | ✓ | ✓ |
| float cosf ( float x ) <br><sub>Calculate the cosine of the input argument.</sub> | ✓ | ✓ |
| float coshf ( float x ) <br><sub>Calculate the hyperbolic cosine of the input argument.</sub> | ✓ | ✓ |
| float erfcf ( float x ) <br><sub>Calculate the complementary error function of the input argument.</sub> | ✓ | ✓ |
| float erff ( float x ) <br><sub>Calculate the error function of the input argument.</sub> | ✓ | ✓ |
| float exp10f ( float x ) <br><sub>Calculate the base 10 exponential of the input argument.</sub> | ✓ | ✓ |
| float exp2f ( float x ) <br><sub>Calculate the base 2 exponential of the input argument.</sub> | ✓ | ✓ |
| float expf ( float x ) <br><sub>Calculate the base e exponential of the input argument.</sub> | ✓ | ✓ |
| float expm1f ( float x ) <br><sub>Calculate the base e exponential of the input argument, minus 1.</sub> | ✓ | ✓ |
| float fabsf ( float x ) <br><sub>Calculate the absolute value of its argument.</sub> | ✓ | ✓ |
| float fdimf ( float x, float y ) <br><sub>Compute the positive difference between `x` and `y`.</sub> | ✓ | ✓ |
| float floorf ( float x ) <br><sub>Calculate the largest integer less than or equal to `x`.</sub> | ✓ | ✓ |
| float fmaf ( float x, float y, float z ) <br><sub>Compute `x × y + z` as a single operation.</sub> | ✓ | ✓ |
| float fmaxf ( float x, float y ) <br><sub>Determine the maximum numeric value of the arguments.</sub> | ✓ | ✓ |
| float fminf ( float x, float y ) <br><sub>Determine the minimum numeric value of the arguments.</sub> | ✓ | ✓ |
| float fmodf ( float x, float y ) <br><sub>Calculate the floating-point remainder of `x / y`.</sub> | ✓ | ✓ |
| float frexpf ( float x, int* nptr ) <br><sub>Extract mantissa and exponent of a floating-point value.</sub> | ✓ | ✗ |
| float hypotf ( float x, float y ) <br><sub>Calculate the square root of the sum of squares of two arguments.</sub> | ✓ | ✓ |
| int ilogbf ( float x ) <br><sub>Compute the unbiased integer exponent of the argument.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1] isfinite ( float a ) <br><sub>Determine whether argument is finite.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1]</sup> isinf ( float a ) <br><sub>Determine whether argument is infinite.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1]</sup> isnan ( float a ) <br><sub>Determine whether argument is a NaN.</sub> | ✓ | ✓ |
| float ldexpf ( float x, int exp ) <br><sub>Calculate the value of x ⋅ 2<sup>exp</sup>.</sub> | ✓ | ✓ |
| float log10f ( float x ) <br><sub>Calculate the base 10 logarithm of the input argument.</sub> | ✓ | ✓ |
| float log1pf ( float x ) <br><sub>Calculate the value of log<sub>e</sub>( 1 + x ).</sub> | ✓ | ✓ |
| float logbf ( float x ) <br><sub>Calculate the floating point representation of the exponent of the input argument.</sub> | ✓ | ✓ |
| float log2f ( float x ) <br><sub>Calculate the base 2 logarithm of the input argument.</sub> | ✓ | ✓ |
| float logf ( float x ) <br><sub>Calculate the natural logarithm of the input argument.</sub> | ✓ | ✓ |
| float modff ( float x, float* iptr ) <br><sub>Break down the input argument into fractional and integral parts.</sub> | ✓ | ✗ |
| float nanf ( const char* tagp ) <br><sub>Returns "Not a Number" value.</sub> | ✗ | ✓ |
| float nearbyintf ( float x ) <br><sub>Round the input argument to the nearest integer.</sub> | ✓ | ✓ |
| float powf ( float x, float y ) <br><sub>Calculate the value of first argument to the power of second argument.</sub> | ✓ | ✓ |
| float remainderf ( float x, float y ) <br><sub>Compute single-precision floating-point remainder.</sub> | ✓ | ✓ |
| float remquof ( float x, float y, int* quo ) <br><sub>Compute single-precision floating-point remainder and part of quotient.</sub> | ✓ | ✗ |
| float roundf ( float x ) <br><sub>Round to nearest integer value in floating-point.</sub> | ✓ | ✓ |
| float scalbnf ( float x, int n ) <br><sub>Scale floating-point input by integer power of two.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1]</sup> signbit ( float a ) <br><sub>Return the sign bit of the input.</sub> | ✓ | ✓ |
| void sincosf ( float x, float* sptr, float* cptr ) <br><sub>Calculate the sine and cosine of the first input argument.</sub> | ✓ | ✗ |
| float sinf ( float x ) <br><sub>Calculate the sine of the input argument.</sub> | ✓ | ✓ |
| float sinhf ( float x ) <br><sub>Calculate the hyperbolic sine of the input argument.</sub> | ✓ | ✓ |
| float sqrtf ( float x ) <br><sub>Calculate the square root of the input argument.</sub> | ✓ | ✓ |
| float tanf ( float x ) <br><sub>Calculate the tangent of the input argument.</sub> | ✓ | ✓ |
| float tanhf ( float x ) <br><sub>Calculate the hyperbolic tangent of the input argument.</sub> | ✓ | ✓ |
| float truncf ( float x ) <br><sub>Truncate input argument to the integral part.</sub> | ✓ | ✓ |
| float tgammaf ( float x ) <br><sub>Calculate the gamma function of the input argument.</sub> | ✓ | ✓ |
| float erfcinvf ( float y ) <br><sub>Calculate the inverse complementary function of the input argument.</sub> | ✓ | ✓ |
| float erfcxf ( float x ) <br><sub>Calculate the scaled complementary error function of the input argument.</sub> | ✓ | ✓ |
| float erfinvf ( float y ) <br><sub>Calculate the inverse error function of the input argument.</sub> | ✓ | ✓ |
| float fdividef ( float x, float y ) <br><sub>Divide two floating point values.</sub> | ✓ | ✓ |
| float frexpf ( float x, int *nptr ) <br><sub>Extract mantissa and exponent of a floating-point value.</sub> | ✓ | ✓ |
| float j0f ( float x ) <br><sub>Calculate the value of the Bessel function of the first kind of order 0 for the input argument.</sub> | ✓ | ✓ |
| float j1f ( float x ) <br><sub>Calculate the value of the Bessel function of the first kind of order 1 for the input argument.</sub> | ✓ | ✓ |
| float jnf ( int n, float x ) <br><sub>Calculate the value of the Bessel function of the first kind of order n for the input argument.</sub> | ✓ | ✓ |
| float lgammaf ( float x ) <br><sub>Calculate the natural logarithm of the absolute value of the gamma function of the input argument.</sub> | ✓ | ✓ |
| long long int llrintf ( float x ) <br><sub>Round input to nearest integer value.</sub> | ✓ | ✓ |
| long long int llroundf ( float x ) <br><sub>Round to nearest integer value.</sub> | ✓ | ✓ |
| long int lrintf ( float x ) <br><sub>Round input to nearest integer value.</sub> | ✓ | ✓ |
| long int lroundf ( float x ) <br><sub>Round to nearest integer value.</sub> | ✓ | ✓ |
| float modff ( float x, float *iptr ) <br><sub>Break down the input argument into fractional and integral parts.</sub> | ✓ | ✓ |
| float nextafterf ( float x, float y ) <br><sub>Returns next representable single-precision floating-point value after argument.</sub> | ✓ | ✓ |
| float norm3df ( float a, float b, float c ) <br><sub>Calculate the square root of the sum of squares of three coordinates of the argument.</sub> | ✓ | ✓ |
| float norm4df ( float a, float b, float c, float d ) <br><sub>Calculate the square root of the sum of squares of four coordinates of the argument.</sub> | ✓ | ✓ |
| float normcdff ( float y ) <br><sub>Calculate the standard normal cumulative distribution function.</sub> | ✓ | ✓ |
| float normcdfinvf ( float y ) <br><sub>Calculate the inverse of the standard normal cumulative distribution function.</sub> | ✓ | ✓ |
| float normf ( int dim, const float *a ) <br><sub>Calculate the square root of the sum of squares of any number of coordinates.</sub> | ✓ | ✓ |
| float rcbrtf ( float x ) <br><sub>Calculate the reciprocal cube root function.</sub> | ✓ | ✓ |
| float remquof ( float x, float y, int *quo ) <br><sub>Compute single-precision floating-point remainder and part of quotient.</sub> | ✓ | ✓ |
| float rhypotf ( float x, float y ) <br><sub>Calculate one over the square root of the sum of squares of two arguments.</sub> | ✓ | ✓ |
| float rintf ( float x ) <br><sub>Round input to nearest integer value in floating-point.</sub> | ✓ | ✓ |
| float rnorm3df ( float a, float b, float c ) <br><sub>Calculate one over the square root of the sum of squares of three coordinates of the argument.</sub> | ✓ | ✓ |
| float rnorm4df ( float a, float b, float c, float d ) <br><sub>Calculate one over the square root of the sum of squares of four coordinates of the argument.</sub> | ✓ | ✓ |
| float rnormf ( int dim, const float *a ) <br><sub>Calculate the reciprocal of square root of the sum of squares of any number of coordinates.</sub> | ✓ | ✓ |
| float scalblnf ( float x, long int n ) <br><sub>Scale floating-point input by integer power of two.</sub> | ✓ | ✓ |
| void sincosf ( float x, float *sptr, float *cptr ) <br><sub>Calculate the sine and cosine of the first input argument.</sub> | ✓ | ✓ |
| void sincospif ( float x, float *sptr, float *cptr ) <br><sub>Calculate the sine and cosine of the first input argument multiplied by PI.</sub> | ✓ | ✓ |
| float y0f ( float x ) <br><sub>Calculate the value of the Bessel function of the second kind of order 0 for the input argument.</sub> | ✓ | ✓ |
| float y1f ( float x ) <br><sub>Calculate the value of the Bessel function of the second kind of order 1 for the input argument.</sub> | ✓ | ✓ |
| float ynf ( int n, float x ) <br><sub>Calculate the value of the Bessel function of the second kind of order n for the input argument.</sub> | ✓ | ✓ |
[^f1]: __RETURN_TYPE is dependent on compiler. It is usually 'int' for C compilers and 'bool' for C++ compilers.
### Double Precision Mathematical Functions
Following is the list of supported double precision mathematical functions.
| **Function** | **Supported on Host** | **Supported on Device** |
| --- | --- | --- |
| double acos ( double x ) <br><sub>Calculate the arc cosine of the input argument.</sub> | ✓ | ✓ |
| double acosh ( double x ) <br><sub>Calculate the nonnegative arc hyperbolic cosine of the input argument.</sub> | ✓ | ✓ |
| double asin ( double x ) <br><sub>Calculate the arc sine of the input argument.</sub> | ✓ | ✓ |
| double asinh ( double x ) <br><sub> Calculate the arc hyperbolic sine of the input argument.</sub> | ✓ | ✓ |
| double atan ( double x ) <br><sub>Calculate the arc tangent of the input argument.</sub> | ✓ | ✓ |
| double atan2 ( double y, double x ) <br><sub>Calculate the arc tangent of the ratio of first and second input arguments.</sub> | ✓ | ✓ |
| double atanh ( double x ) <br><sub>Calculate the arc hyperbolic tangent of the input argument.</sub> | ✓ | ✓ |
| double cbrt ( double x ) <br><sub>Calculate the cube root of the input argument.</sub> | ✓ | ✓ |
| double ceil ( double x ) <br><sub>Calculate ceiling of the input argument.</sub> | ✓ | ✓ |
| double copysign ( double x, double y ) <br><sub>Create value with given magnitude, copying sign of second value.</sub> | ✓ | ✓ |
| double cos ( double x ) <br><sub>Calculate the cosine of the input argument.</sub> | ✓ | ✓ |
| double cosh ( double x ) <br><sub>Calculate the hyperbolic cosine of the input argument.</sub> | ✓ | ✓ |
| double erf ( double x ) <br><sub>Calculate the error function of the input argument.</sub> | ✓ | ✓ |
| double erfc ( double x ) <br><sub>Calculate the complementary error function of the input argument.</sub> | ✓ | ✓ |
| double exp ( double x ) <br><sub>Calculate the base e exponential of the input argument.</sub> | ✓ | ✓ |
| double exp10 ( double x ) <br><sub>Calculate the base 10 exponential of the input argument.</sub> | ✓ | ✓ |
| double exp2 ( double x ) <br><sub>Calculate the base 2 exponential of the input argument.</sub> | ✓ | ✓ |
| double expm1 ( double x ) <br><sub>Calculate the base e exponential of the input argument, minus 1.</sub> | ✓ | ✓ |
| double fabs ( double x ) <br><sub>Calculate the absolute value of the input argument.</sub> | ✓ | ✓ |
| double fdim ( double x, double y ) <br><sub>Compute the positive difference between `x` and `y`.</sub> | ✓ | ✓ |
| double floor ( double x ) <br><sub>Calculate the largest integer less than or equal to `x`.</sub> | ✓ | ✓ |
| double fma ( double x, double y, double z ) <br><sub>Compute `x × y + z` as a single operation.</sub> | ✓ | ✓ |
| double fmax ( double , double ) <br><sub>Determine the maximum numeric value of the arguments.</sub> | ✓ | ✓ |
| double fmin ( double x, double y ) <br><sub>Determine the minimum numeric value of the arguments.</sub> | ✓ | ✓ |
| double fmod ( double x, double y ) <br><sub>Calculate the floating-point remainder of `x / y`.</sub> | ✓ | ✓ |
| double frexp ( double x, int* nptr ) <br><sub>Extract mantissa and exponent of a floating-point value.</sub> | ✓ | ✗ |
| double hypot ( double x, double y ) <br><sub>Calculate the square root of the sum of squares of two arguments.</sub> | ✓ | ✓ |
| int ilogb ( double x ) <br><sub>Compute the unbiased integer exponent of the argument.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1] isfinite ( double a ) <br><sub>Determine whether argument is finite.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1]</sup> isinf ( double a ) <br><sub>Determine whether argument is infinite.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1]</sup> isnan ( double a ) <br><sub>Determine whether argument is a NaN.</sub> | ✓ | ✓ |
| double ldexp ( double x, int exp ) <br><sub>Calculate the value of x ⋅ 2<sup>exp</sup>.</sub> | ✓ | ✓ |
| double log ( double x ) <br><sub>Calculate the base e logarithm of the input argument.</sub> | ✓ | ✓ |
| double log10 ( double x ) <br><sub>Calculate the base 10 logarithm of the input argument.</sub> | ✓ | ✓ |
| double log1p ( double x ) <br><sub>Calculate the value of log<sub>e</sub>( 1 + x ).</sub> | ✓ | ✓ |
| double log2 ( double x ) <br><sub>Calculate the base 2 logarithm of the input argument.</sub> | ✓ | ✓ |
| double logb ( double x ) <br><sub>Calculate the floating point representation of the exponent of the input argument.</sub> | ✓ | ✓ |
| double modf ( double x, double* iptr ) <br><sub>Break down the input argument into fractional and integral parts.</sub> | ✓ | ✗ |
| double nan ( const char* tagp ) <br><sub>Returns "Not a Number" value.</sub> | ✗ | ✓ |
| double nearbyint ( double x ) <br><sub>Round the input argument to the nearest integer.</sub> | ✓ | ✓ |
| double pow ( double x, double y ) <br><sub>Calculate the value of first argument to the power of second argument.</sub> | ✓ | ✓ |
| double remainder ( double x, double y ) <br><sub>Compute double-precision floating-point remainder.</sub> | ✓ | ✓ |
| double remquo ( double x, double y, int* quo ) <br><sub>Compute double-precision floating-point remainder and part of quotient.</sub> | ✓ | ✗ |
| double round ( double x ) <br><sub>Round to nearest integer value in floating-point.</sub> | ✓ | ✓ |
| double scalbn ( double x, int n ) <br><sub>Scale floating-point input by integer power of two.</sub> | ✓ | ✓ |
| __RETURN_TYPE[^f1] signbit ( double a ) <br><sub>Return the sign bit of the input.</sub> | ✓ | ✓ |
| double sin ( double x ) <br><sub>Calculate the sine of the input argument.</sub> | ✓ | ✓ |
| void sincos ( double x, double* sptr, double* cptr ) <br><sub>Calculate the sine and cosine of the first input argument.</sub> | ✓ | ✗ |
| double sinh ( double x ) <br><sub>Calculate the hyperbolic sine of the input argument.</sub> | ✓ | ✓ |
| double sqrt ( double x ) <br><sub>Calculate the square root of the input argument.</sub> | ✓ | ✓ |
| double tan ( double x ) <br><sub>Calculate the tangent of the input argument.</sub> | ✓ | ✓ |
| double tanh ( double x ) <br><sub>Calculate the hyperbolic tangent of the input argument.</sub> | ✓ | ✓ |
| double tgamma ( double x ) <br><sub>Calculate the gamma function of the input argument.</sub> | ✓ | ✓ |
| double trunc ( double x ) <br><sub>Truncate input argument to the integral part.</sub> | ✓ | ✓ |
| double erfcinv ( double y ) <br><sub>Calculate the inverse complementary function of the input argument.</sub> | ✓ | ✓ |
| double erfcx ( double x ) <br><sub>Calculate the scaled complementary error function of the input argument.</sub> | ✓ | ✓ |
| double erfinv ( double y ) <br><sub>Calculate the inverse error function of the input argument.</sub> | ✓ | ✓ |
| double frexp ( float x, int *nptr ) <br><sub>Extract mantissa and exponent of a floating-point value.</sub> | ✓ | ✓ |
| double j0 ( double x ) <br><sub>Calculate the value of the Bessel function of the first kind of order 0 for the input argument.</sub> | ✓ | ✓ |
| double j1 ( double x ) <br><sub>Calculate the value of the Bessel function of the first kind of order 1 for the input argument.</sub> | ✓ | ✓ |
| double jn ( int n, double x ) <br><sub>Calculate the value of the Bessel function of the first kind of order n for the input argument.</sub> | ✓ | ✓ |
| double lgamma ( double x ) <br><sub>Calculate the natural logarithm of the absolute value of the gamma function of the input argument.</sub> | ✓ | ✓ |
| long long int llrint ( double x ) <br><sub>Round input to nearest integer value.</sub> | ✓ | ✓ |
| long long int llround ( double x ) <br><sub>Round to nearest integer value.</sub> | ✓ | ✓ |
| long int lrint ( double x ) <br><sub>Round input to nearest integer value.</sub> | ✓ | ✓ |
| long int lround ( double x ) <br><sub>Round to nearest integer value.</sub> | ✓ | ✓ |
| double modf ( double x, double *iptr ) <br><sub>Break down the input argument into fractional and integral parts.</sub> | ✓ | ✓ |
| double nextafter ( double x, double y ) <br><sub>Returns next representable single-precision floating-point value after argument.</sub> | ✓ | ✓ |
| double norm3d ( double a, double b, double c ) <br><sub>Calculate the square root of the sum of squares of three coordinates of the argument.</sub> | ✓ | ✓ |
| float norm4d ( double a, double b, double c, double d ) <br><sub>Calculate the square root of the sum of squares of four coordinates of the argument.</sub> | ✓ | ✓ |
| double normcdf ( double y ) <br><sub>Calculate the standard normal cumulative distribution function.</sub> | ✓ | ✓ |
| double normcdfinv ( double y ) <br><sub>Calculate the inverse of the standard normal cumulative distribution function.</sub> | ✓ | ✓ |
| double rcbrt ( double x ) <br><sub>Calculate the reciprocal cube root function.</sub> | ✓ | ✓ |
| double remquo ( double x, double y, int *quo ) <br><sub>Compute single-precision floating-point remainder and part of quotient.</sub> | ✓ | ✓ |
| double rhypot ( double x, double y ) <br><sub>Calculate one over the square root of the sum of squares of two arguments.</sub> | ✓ | ✓ |
| double rint ( double x ) <br><sub>Round input to nearest integer value in floating-point.</sub> | ✓ | ✓ |
| double rnorm3d ( double a, double b, double c ) <br><sub>Calculate one over the square root of the sum of squares of three coordinates of the argument.</sub> | ✓ | ✓ |
| double rnorm4d ( double a, double b, double c, double d ) <br><sub>Calculate one over the square root of the sum of squares of four coordinates of the argument.</sub> | ✓ | ✓ |
| double rnorm ( int dim, const double *a ) <br><sub>Calculate the reciprocal of square root of the sum of squares of any number of coordinates.</sub> | ✓ | ✓ |
| double scalbln ( double x, long int n ) <br><sub>Scale floating-point input by integer power of two.</sub> | ✓ | ✓ |
| void sincos ( double x, double *sptr, double *cptr ) <br><sub>Calculate the sine and cosine of the first input argument.</sub> | ✓ | ✓ |
| void sincospi ( double x, double *sptr, double *cptr ) <br><sub>Calculate the sine and cosine of the first input argument multiplied by PI.</sub> | ✓ | ✓ |
| double y0f ( double x ) <br><sub>Calculate the value of the Bessel function of the second kind of order 0 for the input argument.</sub> | ✓ | ✓ |
| double y1 ( double x ) <br><sub>Calculate the value of the Bessel function of the second kind of order 1 for the input argument.</sub> | ✓ | ✓ |
| double yn ( int n, double x ) <br><sub>Calculate the value of the Bessel function of the second kind of order n for the input argument.</sub> | ✓ | ✓ |
### Integer Intrinsics
Following is the list of supported integer intrinsics. Note that intrinsics are supported on device only.
| **Function** |
| --- |
| unsigned int __brev ( unsigned int x ) <br><sub>Reverse the bit order of a 32 bit unsigned integer.</sub> |
| unsigned long long int __brevll ( unsigned long long int x ) <br><sub>Reverse the bit order of a 64 bit unsigned integer. </sub> |
| int __clz ( int x ) <br><sub>Return the number of consecutive high-order zero bits in a 32 bit integer.</sub> |
| unsigned int __clz(unsigned int x) <br><sub>Return the number of consecutive high-order zero bits in 32 bit unsigned integer.</sub> |
| int __clzll ( long long int x ) <br><sub>Count the number of consecutive high-order zero bits in a 64 bit integer.</sub> |
| unsigned int __clzll(long long int x) <br><sub>Return the number of consecutive high-order zero bits in 64 bit signed integer.</sub> |
| unsigned int __ffs(unsigned int x) <br><sub>Find the position of least signigicant bit set to 1 in a 32 bit unsigned integer.[^f3]</sub> |
| unsigned int __ffs(int x) <br><sub>Find the position of least signigicant bit set to 1 in a 32 bit signed integer.</sub> |
| unsigned int __ffsll(unsigned long long int x) <br><sub>Find the position of least signigicant bit set to 1 in a 64 bit unsigned integer.[^f3]</sup></sub> |
| unsigned int __ffsll(long long int x) <br><sub>Find the position of least signigicant bit set to 1 in a 64 bit signed integer.</sub> |
| unsigned int __popc ( unsigned int x ) <br><sub>Count the number of bits that are set to 1 in a 32 bit integer.</sub> |
| unsigned int __popcll ( unsigned long long int x )<br><sub>Count the number of bits that are set to 1 in a 64 bit integer.</sub> |
| int __mul24 ( int x, int y )<br><sub>Multiply two 24bit integers.</sub> |
| unsigned int __umul24 ( unsigned int x, unsigned int y )<br><sub>Multiply two 24bit unsigned integers.</sub> |
<sub>[^f3]
The HIP-Clang implementation of __ffs() and __ffsll() contains code to add a constant +1 to produce the ffs result format.
For the cases where this overhead is not acceptable and programmer is willing to specialize for the platform,
HIP-Clang provides __lastbit_u32_u32(unsigned int input) and __lastbit_u32_u64(unsigned long long int input).
The index returned by __lastbit_ instructions starts at -1, while for ffs the index starts at 0.
### Floating-point Intrinsics
Following is the list of supported floating-point intrinsics. Note that intrinsics are supported on device only.
| **Function** |
| --- |
| float __cosf ( float x ) <br><sub>Calculate the fast approximate cosine of the input argument.</sub> |
| float __expf ( float x ) <br><sub>Calculate the fast approximate base e exponential of the input argument.</sub> |
| float __frsqrt_rn ( float x ) <br><sub>Compute `1 / √x` in round-to-nearest-even mode.</sub> |
| float __fsqrt_rn ( float x ) <br><sub>Compute `√x` in round-to-nearest-even mode.</sub> |
| float __log10f ( float x ) <br><sub>Calculate the fast approximate base 10 logarithm of the input argument.</sub> |
| float __log2f ( float x ) <br><sub>Calculate the fast approximate base 2 logarithm of the input argument.</sub> |
| float __logf ( float x ) <br><sub>Calculate the fast approximate base e logarithm of the input argument.</sub> |
| float __powf ( float x, float y ) <br><sub>Calculate the fast approximate of x<sup>y</sup>.</sub> |
| float __sinf ( float x ) <br><sub>Calculate the fast approximate sine of the input argument.</sub> |
| float __tanf ( float x ) <br><sub>Calculate the fast approximate tangent of the input argument.</sub> |
| double __dsqrt_rn ( double x ) <br><sub>Compute `√x` in round-to-nearest-even mode.</sub> |
## Texture Functions
The supported Texture functions are listed in header files "texture_fetch_functions.h" and "texture_indirect_functions.h" in [HIP-AMD backend repository](https://github.com/ROCm/clr/blob/develop/hipamd/include/hip/amd_detail).
Texture functions are not supported on some devices.
Macro __HIP_NO_IMAGE_SUPPORT == 1 can be used to check whether texture functions are not supported in device code.
Attribute hipDeviceAttributeImageSupport can be queried to check whether texture functions are supported in host runtime code.
## Surface Functions
Surface functions are not supported.
## Timer Functions
HIP provides the following built-in functions for reading a high-resolution timer from the device.
```
clock_t clock()
long long int clock64()
```
Returns the value of counter that is incremented every clock cycle on device. Difference in values returned provides the cycles used.
```
long long int wall_clock64()
```
Returns wall clock count at a constant frequency on the device, which can be queried via HIP API with hipDeviceAttributeWallClockRate attribute of the device in HIP application code, for example,
```
int wallClkRate = 0; //in kilohertz
HIPCHECK(hipDeviceGetAttribute(&wallClkRate, hipDeviceAttributeWallClockRate, deviceId));
```
Where hipDeviceAttributeWallClockRate is a device attribute.
Note that, wall clock frequency is a per-device attribute.
## Atomic Functions
Atomic functions execute as read-modify-write operations residing in global or shared memory. No other device or thread can observe or modify the memory location during an atomic operation. If multiple instructions from different devices or threads target the same memory location, the instructions are serialized in an undefined order.
HIP adds new APIs with _system as suffix to support system scope atomic operations. For example, the `atomicAnd` function is meant to be atomic and coherent within the GPU device executing the function. `atomicAnd_system` will allow developers to extend the atomic operation to system scope, from the GPU device to other CPUs and GPU devices in the system.
HIP supports the following atomic operations.
| **Function** | **Supported in HIP** | **Supported in CUDA** |
| -------------------------------------------------------------------------------------------------------------------- | --------------------- | ---------------------- |
| int atomicAdd(int* address, int val) | ✓ | ✓ |
| int atomicAdd_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicAdd(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicAdd_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicAdd(unsigned long long* address,unsigned long long val) | ✓ | ✓ |
| unsigned long long atomicAdd_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
| float atomicAdd(float* address, float val) | ✓ | ✓ |
| float atomicAdd_system(float* address, float val) | ✓ | ✓ |
| double atomicAdd(double* address, double val) | ✓ | ✓ |
| double atomicAdd_system(double* address, double val) | ✓ | ✓ |
| float unsafeAtomicAdd(float* address, float val) | ✓ | ✗ |
| float safeAtomicAdd(float* address, float val) | ✓ | ✗ |
| double unsafeAtomicAdd(double* address, double val) | ✓ | ✗ |
| double safeAtomicAdd(double* address, double val) | ✓ | ✗ |
| int atomicSub(int* address, int val) | ✓ | ✓ |
| int atomicSub_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicSub(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicSub_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| int atomicExch(int* address, int val) | ✓ | ✓ |
| int atomicExch_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicExch(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicExch_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicExch(unsigned long long int* address,unsigned long long int val) | ✓ | ✓ |
| unsigned long long atomicExch_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
| unsigned long long atomicExch_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
| float atomicExch(float* address, float val) | ✓ | ✓ |
| int atomicMin(int* address, int val) | ✓ | ✓ |
| int atomicMin_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicMin(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicMin_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicMin(unsigned long long* address,unsigned long long val) | ✓ | ✓ |
| int atomicMax(int* address, int val) | ✓ | ✓ |
| int atomicMax_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicMax(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicMax_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicMax(unsigned long long* address,unsigned long long val) | ✓ | ✓ |
| unsigned int atomicInc(unsigned int* address) | ✗ | ✓ |
| unsigned int atomicDec(unsigned int* address) | ✗ | ✓ |
| int atomicCAS(int* address, int compare, int val) | ✓ | ✓ |
| int atomicCAS_system(int* address, int compare, int val) | ✓ | ✓ |
| unsigned int atomicCAS(unsigned int* address,unsigned int compare,unsigned int val) | ✓ | ✓ |
| unsigned int atomicCAS_system(unsigned int* address, unsigned int compare, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicCAS(unsigned long long* address,unsigned long long compare,unsigned long long val) | ✓ | ✓ |
| unsigned long long atomicCAS_system(unsigned long long* address, unsigned long long compare, unsigned long long val) | ✓ | ✓ |
| int atomicAnd(int* address, int val) | ✓ | ✓ |
| int atomicAnd_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicAnd(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicAnd_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicAnd(unsigned long long* address,unsigned long long val) | ✓ | ✓ |
| unsigned long long atomicAnd_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
| int atomicOr(int* address, int val) | ✓ | ✓ |
| int atomicOr_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicOr(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicOr_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned int atomicOr_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicOr(unsigned long long int* address,unsigned long long val) | ✓ | ✓ |
| unsigned long long atomicOr_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
| int atomicXor(int* address, int val) | ✓ | ✓ |
| int atomicXor_system(int* address, int val) | ✓ | ✓ |
| unsigned int atomicXor(unsigned int* address,unsigned int val) | ✓ | ✓ |
| unsigned int atomicXor_system(unsigned int* address, unsigned int val) | ✓ | ✓ |
| unsigned long long atomicXor(unsigned long long* address,unsigned long long val)) | ✓ | ✓ |
| unsigned long long atomicXor_system(unsigned long long* address, unsigned long long val) | ✓ | ✓ |
### Unsafe Floating-Point Atomic RMW Operations
Some HIP devices support fast atomic read-modify-write (RMW) operations on floating-point values.
For example, `atomicAdd` on single- or double-precision floating-point values may generate a hardware RMW instruction that is faster than emulating the atomic operation using an atomic compare-and-swap (CAS) loop.
On some devices, these fast atomic RMW instructions can produce different results when compared with the same functions implemented with atomic CAS loops.
For example, some devices will produce incorrect answers if a fast atomic floating-point RMW instruction targets fine-grained memory allocations.
As another example, some devices will use different rounding or denormal modes when using fast atomic floating-point RMW instructions.
As such, the HIP-Clang compiler offers a compile-time option for users to choose whether their code will use the fast, potentially unsafe, atomic instructions.
On devices that support these fast, but unsafe, floating-point atomic RMW instructions, the compiler option `-munsafe-fp-atomics` will allow the compiler to generate them when it sees appropriate atomic RMW function calls.
By passing the `-munsafe-fp-atomics` flag to the compiler, the user is indicating that all floating-point atomic function calls are allowed to use an unsafe version if one exists.
For instance, on some devices, this flag indicates to the compiler that that no floating-point `atomicAdd` function targets fine-grained memory.
If the user instead compiles with `-mno-unsafe-fp-atomics`, the user is telling the compiler to never use a floating-point atomic RMW that may not be safe.
The compiler will default to not producing unsafe floating-point atomic RMW instructions, so the `-mno-unsafe-fp-atomics` compilation option is not strictly necessary.
Explicitly passing this flag to the compiler is good practice, however.
Whenever either of the two options described above, `-munsafe-fp-atomics` and `-mno-unsafe-fp-atomics` are passed to the compiler's command line, they are applied globally for that entire compilation.
If only a subset of the atomic RMW function calls could safely use the faster floating-point atomic RMW instructions, the developer would instead need to compile with `-mno-unsafe-fp-atomics` in order to ensure the remaining atomic RMW function calls produce correct results.
Towards this end, HIP has four extra functions to help developers more precisely control which floating-point atomic RMW functions produce unsafe atomic RMW instructions:
- `float unsafeAtomicAdd(float* address, float val)`
- `double unsafeAtomicAdd(double* address, double val)`
- These functions will always produce fast atomic RMW instructions on devices that have them, even when `-mno-unsafe-fp-atomics` is set
- `float safeAtomicAdd(float* address, float val)`
- `double safeAtomicAdd(double* address, double val)`
- These functions will always produce safe atomic RMW operations, even when `-munsafe-fp-atomics` is set
(warp_cross_lane_functions)=
## Warp Cross-Lane Functions
Threads in a warp are referred to as *lanes* and are numbered from 0 to warpSize -- 1.
Warp cross-lane functions operate across all lanes in a warp. The hardware guarantees that all warp lanes will execute in lockstep, so additional synchronization is unnecessary, and the instructions use no shared memory.
Note that Nvidia and AMD devices have different warp sizes, so portable code should use the warpSize built-ins to query the warp size. Hipified code from the Cuda path requires careful review to ensure it doesn't assume a waveSize of 32. "Wave-aware" code that assumes a waveSize of 32 will run on a wave-64 machine, but it will utilize only half of the machine resources. WarpSize built-ins should only be used in device functions and its value depends on GPU arch. Users should not assume warpSize to be a compile-time constant. Host functions should use hipGetDeviceProperties to get the default warp size of a GPU device:
```
cudaDeviceProp props;
cudaGetDeviceProperties(&props, deviceID);
int w = props.warpSize;
// implement portable algorithm based on w (rather than assume 32 or 64)
```
Note that assembly kernels may be built for a warp size which is different than the default warp size.
All mask values either returned or accepted by these builtins are 64-bit
unsigned integer values, even when compiled for a wave-32 device, where all the
higher bits are unused. CUDA code ported to HIP requires changes to ensure that
the correct type is used.
Note that the `__sync` variants are made available in ROCm 6.2, but disabled by
default to help with the transition to 64-bit masks. They can be enabled by
setting the preprocessor macro `HIP_ENABLE_WARP_SYNC_BUILTINS`. These builtins
will be enabled unconditionally in ROCm 6.3. Wherever possible, the
implementation includes a static assert to check that the program source uses
the correct type for the mask.
### Warp Vote and Ballot Functions
```
int __all(int predicate)
int __any(int predicate)
unsigned long long __ballot(int predicate)
unsigned long long __activemask()
int __all_sync(unsigned long long mask, int predicate)
int __any_sync(unsigned long long mask, int predicate)
int __ballot(unsigned long long mask, int predicate)
```
`__any` and `__all` provide a summary view of the predicates evaluated by the
participating lanes.
- `__any()` returns 1 if the predicate is non-zero for any participating lane,
or returns 0 otherwise.
- `__all()` returns 1 if the predicate is non-zero for all participating lanes,
or returns 0 otherwise.
Applications can test whether the target platform supports the any/all instruction using the `hasWarpVote` device property or the HIP_ARCH_HAS_WARP_VOTE compiler define.
`__ballot` returns a bit mask containing the 1-bit predicate value from each
lane. The nth bit of the result contains the 1 bit contributed by the nth warp
lane.
`__activemask()` returns a bit mask of currently active warp lanes. The nth bit
of the result is 1 if the nth warp lane is active.
Note that the `__ballot` and `__activemask` builtins in HIP have a 64-bit return
value (unlike the 32-bit value returned by the CUDA builtins). Code ported from
CUDA should be adapted to support the larger warp sizes that the HIP version
requires.
Applications can test whether the target platform supports the `__ballot` or
`__activemask` instructions using the `hasWarpBallot` device property in host
code or the `HIP_ARCH_HAS_WARP_BALLOT` macro defined by the compiler for device
code.
The `_sync` variants require a 64-bit unsigned integer mask argument that
specifies the lanes in the warp that will participate in cross-lane
communication with the calling lane. Each participating thread must have its own
bit set in its mask argument, and all active threads specified in any mask
argument must execute the same call with the same mask, otherwise the result is
undefined.
### Warp Match Functions
```
unsigned long long __match_any(T value)
unsigned long long __match_all(T value, int *pred)
unsigned long long __match_any_sync(unsigned long long mask, T value)
unsigned long long __match_all_sync(unsigned long long mask, T value, int *pred)
```
`T` can be a 32-bit integer type, 64-bit integer type or a single precision or
double precision floating point type.
`__match_any` returns a bit mask containing a 1-bit for every participating lane
if and only if that lane has the same value in `value` as the current lane, and
a 0-bit for all other lanes.
`__match_all` returns a bit mask containing a 1-bit for every participating lane
if and only if they all have the same value in `value` as the current lane, and
a 0-bit for all other lanes. The predicate `pred` is set to true if and only if
all participating threads have the same value in `value`.
The `_sync` variants require a 64-bit unsigned integer mask argument that
specifies the lanes in the warp that will participate in cross-lane
communication with the calling lane. Each participating thread must have its own
bit set in its mask argument, and all active threads specified in any mask
argument must execute the same call with the same mask, otherwise the result is
undefined.
### Warp Shuffle Functions
Half-float shuffles are not supported. The default width is warpSize---see [Warp Cross-Lane Functions](#warp-cross-lane-functions). Applications should not assume the warpSize is 32 or 64.
```
int __shfl (T var, int srcLane, int width=warpSize);
int __shfl_up (T var, unsigned int delta, int width=warpSize);
int __shfl_down (T var, unsigned int delta, int width=warpSize);
int __shfl_xor (T var, int laneMask, int width=warpSize);
int __shfl_sync (unsigned long long mask, T var, int srcLane, int width=warpSize);
int __shfl_up_sync (unsigned long long mask, T var, unsigned int delta, int width=warpSize);
int __shfl_down_sync (unsigned long long mask, T var, unsigned int delta, int width=warpSize);
int __shfl_xor_sync (unsigned long long mask, T var, int laneMask, int width=warpSize);
```
`T` can be a 32-bit integer type, 64-bit integer type or a single precision or
double precision floating point type.
The `_sync` variants require a 64-bit unsigned integer mask argument that
specifies the lanes in the warp that will participate in cross-lane
communication with the calling lane. Each participating thread must have its own
bit set in its mask argument, and all active threads specified in any mask
argument must execute the same call with the same mask, otherwise the result is
undefined.
## Cooperative Groups Functions
Cooperative groups is a mechanism for forming and communicating between groups of threads at
a granularity different than the block. This feature was introduced in Cuda 9.
HIP supports the following kernel language cooperative groups types or functions.
| **Function** | **Supported in HIP** | **Supported in CUDA** |
| --- | --- | --- |
| `void thread_group.sync();` | ✓ | ✓ |
| `unsigned thread_group.size();` | ✓ | ✓ |
| `unsigned thread_group.thread_rank()` | ✓ | ✓ |
| `bool thread_group.is_valid();` | ✓ | ✓ |
| `grid_group this_grid()` | ✓ | ✓ |
| `void grid_group.sync()` | ✓ | ✓ |
| `unsigned grid_group.size()` | ✓ | ✓ |
| `unsigned grid_group.thread_rank()` | ✓ | ✓ |
| `bool grid_group.is_valid()` | ✓ | ✓ |
| `multi_grid_group this_multi_grid()` | ✓ | ✓ |
| `void multi_grid_group.sync()` | ✓ | ✓ |
| `unsigned multi_grid_group.size()` | ✓ | ✓ |
| `unsigned multi_grid_group.thread_rank()` | ✓ | ✓ |
| `bool multi_grid_group.is_valid()` | ✓ | ✓ |
| `unsigned multi_grid_group.num_grids()` | ✓ | ✓ |
| `unsigned multi_grid_group.grid_rank()` | ✓ | ✓ |
| `thread_block this_thread_block()` | ✓ | ✓ |
| `multi_grid_group this_multi_grid()` | ✓ | ✓ |
| `void multi_grid_group.sync()` | ✓ | ✓ |
| `void thread_block.sync()` | ✓ | ✓ |
| `unsigned thread_block.size()` | ✓ | ✓ |
| `unsigned thread_block.thread_rank()` | ✓ | ✓ |
| `bool thread_block.is_valid()` | ✓ | ✓ |
| `dim3 thread_block.group_index()` | ✓ | ✓ |
| `dim3 thread_block.thread_index()` | ✓ | ✓ |
## Warp Matrix Functions
Warp matrix functions allow a warp to cooperatively operate on small matrices
whose elements are spread over the lanes in an unspecified manner. This feature
was introduced in Cuda 9.
HIP does not support any of the kernel language warp matrix
types or functions.
| **Function** | **Supported in HIP** | **Supported in CUDA** |
| --- | --- | --- |
| `void load_matrix_sync(fragment<...> &a, const T* mptr, unsigned lda)` | | ✓ |
| `void load_matrix_sync(fragment<...> &a, const T* mptr, unsigned lda, layout_t layout)` | | ✓ |
| `void store_matrix_sync(T* mptr, fragment<...> &a, unsigned lda, layout_t layout)` | | ✓ |
| `void fill_fragment(fragment<...> &a, const T &value)` | | ✓ |
| `void mma_sync(fragment<...> &d, const fragment<...> &a, const fragment<...> &b, const fragment<...> &c , bool sat)` | | ✓ |
## Independent Thread Scheduling
The hardware support for independent thread scheduling introduced in certain architectures
supporting Cuda allows threads to progress independently of each other and enables
intra-warp synchronizations that were previously not allowed.
HIP does not support this type of scheduling.
## Profiler Counter Function
The Cuda `__prof_trigger()` instruction is not supported.
## Assert
The assert function is supported in HIP.
Assert function is used for debugging purpose, when the input expression equals to zero, the execution will be stopped.
```
void assert(int input)
```
There are two kinds of implementations for assert functions depending on the use sceneries,
- One is for the host version of assert, which is defined in assert.h,
- Another is the device version of assert, which is implemented in hip/hip_runtime.h.
Users need to include assert.h to use assert. For assert to work in both device and host functions, users need to include "hip/hip_runtime.h".
HIP provides the function abort() which can be used to terminate the application when terminal failures are detected. It is implemented using the `__builtin_trap()` function.
This function produces a similar effect of using `asm("trap")` in the CUDA code.
Note, in HIP, the function terminates the entire application, while in CUDA, `asm("trap")`only terminates the dispatch and the application continues to run.
## Printf
Printf function is supported in HIP.
The following is a simple example to print information in the kernel.
```
#include <hip/hip_runtime.h>
__global__ void run_printf() { printf("Hello World\n"); }
int main() {
run_printf<<<dim3(1), dim3(1), 0, 0>>>();
}
```
## Device-Side Dynamic Global Memory Allocation
Device-side dynamic global memory allocation is under development. HIP now includes a preliminary
implementation of malloc and free that can be called from device functions.
## `__launch_bounds__`
GPU multiprocessors have a fixed pool of resources (primarily registers and shared memory) which are shared by the actively running warps. Using more resources can increase IPC of the kernel but reduces the resources available for other warps and limits the number of warps that can be simulaneously running. Thus GPUs have a complex relationship between resource usage and performance.
__launch_bounds__ allows the application to provide usage hints that influence the resources (primarily registers) used by the generated code. It is a function attribute that must be attached to a __global__ function:
```
__global__ void `__launch_bounds__`(MAX_THREADS_PER_BLOCK, MIN_WARPS_PER_EXECUTION_UNIT)
MyKernel(hipGridLaunch lp, ...)
...
```
__launch_bounds__ supports two parameters:
- MAX_THREADS_PER_BLOCK - The programmers guarantees that kernel will be launched with threads less than MAX_THREADS_PER_BLOCK. (On NVCC this maps to the .maxntid PTX directive). If no launch_bounds is specified, MAX_THREADS_PER_BLOCK is the maximum block size supported by the device (typically 1024 or larger). Specifying MAX_THREADS_PER_BLOCK less than the maximum effectively allows the compiler to use more resources than a default unconstrained compilation that supports all possible block sizes at launch time.
The threads-per-block is the product of (blockDim.x * blockDim.y * blockDim.z).
- MIN_WARPS_PER_EXECUTION_UNIT - directs the compiler to minimize resource usage so that the requested number of warps can be simultaneously active on a multi-processor. Since active warps compete for the same fixed pool of resources, the compiler must reduce resources required by each warp(primarily registers). MIN_WARPS_PER_EXECUTION_UNIT is optional and defaults to 1 if not specified. Specifying a MIN_WARPS_PER_EXECUTION_UNIT greater than the default 1 effectively constrains the compiler's resource usage.
When launch kernel with HIP APIs, for example, hipModuleLaunchKernel(), HIP will do validation to make sure input kernel dimension size is not larger than specified launch_bounds.
In case exceeded, HIP would return launch failure, if AMD_LOG_LEVEL is set with proper value (for details, please refer to docs/markdown/hip_logging.md), detail information will be shown in the error log message, including
launch parameters of kernel dim size, launch bounds, and the name of the faulting kernel. It's helpful to figure out which is the faulting kernel, besides, the kernel dim size and launch bounds values will also assist in debugging such failures.
### Compiler Impact
The compiler uses these parameters as follows:
- The compiler uses the hints only to manage register usage, and does not automatically reduce shared memory or other resources.
- Compilation fails if compiler cannot generate a kernel which meets the requirements of the specified launch bounds.
- From MAX_THREADS_PER_BLOCK, the compiler derives the maximum number of warps/block that can be used at launch time.
Values of MAX_THREADS_PER_BLOCK less than the default allows the compiler to use a larger pool of registers : each warp uses registers, and this hint constains the launch to a warps/block size which is less than maximum.
- From MIN_WARPS_PER_EXECUTION_UNIT, the compiler derives a maximum number of registers that can be used by the kernel (to meet the required #simultaneous active blocks).
If MIN_WARPS_PER_EXECUTION_UNIT is 1, then the kernel can use all registers supported by the multiprocessor.
- The compiler ensures that the registers used in the kernel is less than both allowed maximums, typically by spilling registers (to shared or global memory), or by using more instructions.
- The compiler may use hueristics to increase register usage, or may simply be able to avoid spilling. The MAX_THREADS_PER_BLOCK is particularly useful in this cases, since it allows the compiler to use more registers and avoid situations where the compiler constrains the register usage (potentially spilling) to meet the requirements of a large block size that is never used at launch time.
### CU and EU Definitions
A compute unit (CU) is responsible for executing the waves of a work-group. It is composed of one or more execution units (EU) which are responsible for executing waves. An EU can have enough resources to maintain the state of more than one executing wave. This allows an EU to hide latency by switching between waves in a similar way to symmetric multithreading on a CPU. In order to allow the state for multiple waves to fit on an EU, the resources used by a single wave have to be limited. Limiting such resources can allow greater latency hiding, but can result in having to spill some register state to memory. This attribute allows an advanced developer to tune the number of waves that are capable of fitting within the resources of an EU. It can be used to ensure at least a certain number will fit to help hide latency, and can also be used to ensure no more than a certain number will fit to limit cache thrashing.
### Porting from CUDA __launch_bounds
CUDA defines a __launch_bounds which is also designed to control occupancy:
```
__launch_bounds(MAX_THREADS_PER_BLOCK, MIN_BLOCKS_PER_MULTIPROCESSOR)
```
- The second parameter __launch_bounds parameters must be converted to the format used __hip_launch_bounds, which uses warps and execution-units rather than blocks and multi-processors (this conversion is performed automatically by hipify tools).
```
MIN_WARPS_PER_EXECUTION_UNIT = (MIN_BLOCKS_PER_MULTIPROCESSOR * MAX_THREADS_PER_BLOCK) / 32
```
The key differences in the interface are:
- Warps (rather than blocks):
The developer is trying to tell the compiler to control resource utilization to guarantee some amount of active Warps/EU for latency hiding. Specifying active warps in terms of blocks appears to hide the micro-architectural details of the warp size, but makes the interface more confusing since the developer ultimately needs to compute the number of warps to obtain the desired level of control.
- Execution Units (rather than multiProcessor):
The use of execution units rather than multiprocessors provides support for architectures with multiple execution units/multi-processor. For example, the AMD GCN architecture has 4 execution units per multiProcessor. The hipDeviceProps has a field executionUnitsPerMultiprocessor.
Platform-specific coding techniques such as #ifdef can be used to specify different launch_bounds for NVCC and HIP-Clang platforms, if desired.
### maxregcount
Unlike nvcc, HIP-Clang does not support the "--maxregcount" option. Instead, users are encouraged to use the hip_launch_bounds directive since the parameters are more intuitive and portable than
micro-architecture details like registers, and also the directive allows per-kernel control rather than an entire file. hip_launch_bounds works on both HIP-Clang and nvcc targets.
## Register Keyword
The register keyword is deprecated in C++, and is silently ignored by both nvcc and HIP-Clang. You can pass the option `-Wdeprecated-register` the compiler warning message.
## Pragma Unroll
Unroll with a bounds that is known at compile-time is supported. For example:
```
#pragma unroll 16 /* hint to compiler to unroll next loop by 16 */
for (int i=0; i<16; i++) ...
```
```
#pragma unroll 1 /* tell compiler to never unroll the loop */
for (int i=0; i<16; i++) ...
```
```
#pragma unroll /* hint to compiler to completely unroll next loop. */
for (int i=0; i<16; i++) ...
```
## In-Line Assembly
GCN ISA In-line assembly, is supported. For example:
```
asm volatile ("v_mac_f32_e32 %0, %2, %3" : "=v" (out[i]) : "0"(out[i]), "v" (a), "v" (in[i]));
```
We insert the GCN isa into the kernel using `asm()` Assembler statement.
`volatile` keyword is used so that the optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations.
`v_mac_f32_e32` is the GCN instruction, for more information please refer - [AMD GCN3 ISA architecture manual](http://gpuopen.com/compute-product/amd-gcn3-isa-architecture-manual/)
Index for the respective operand in the ordered fashion is provided by `%` followed by position in the list of operands
`"v"` is the constraint code (for target-specific AMDGPU) for 32-bit VGPR register, for more info please refer - [Supported Constraint Code List for AMDGPU](https://llvm.org/docs/LangRef.html#supported-constraint-code-list)
Output Constraints are specified by an `"="` prefix as shown above ("=v"). This indicate that assemby will write to this operand, and the operand will then be made available as a return value of the asm expression. Input constraints do not have a prefix - just the constraint code. The constraint string of `"0"` says to use the assigned register for output as an input as well (it being the 0'th constraint).
## C++ Support
The following C++ features are not supported:
- Run-time-type information (RTTI)
- Try/catch
- Virtual functions
Virtual functions are not supported if objects containing virtual function tables are passed between GPU's of different offload arch's, e.g. between gfx906 and gfx1030. Otherwise virtual functions are supported.
## Kernel Compilation
hipcc now supports compiling C++/HIP kernels to binary code objects.
The file format for binary is `.co` which means Code Object. The following command builds the code object using `hipcc`.
`hipcc --genco --offload-arch=[TARGET GPU] [INPUT FILE] -o [OUTPUT FILE]`
```
[TARGET GPU] = GPU architecture
[INPUT FILE] = Name of the file containing kernels
[OUTPUT FILE] = Name of the generated code object file
```
Note: When using binary code objects is that the number of arguments to the kernel is different on HIP-Clang and NVCC path. Refer to the sample in samples/0_Intro/module_api for differences in the arguments to be passed to the kernel.
## gfx-arch-specific-kernel
Clang defined '__gfx*__' macros can be used to execute gfx arch specific codes inside the kernel. Refer to the sample 14_gpu_arch in samples/2_Cookbook.
docs/reference/programming_model.rst
+259
Просмотреть файл
@@ -0,0 +1,259 @@
.. meta::
:description: This chapter describes the HIP programming model, the contract
between the programmer and the compiler/runtime executing the
code.
:keywords: AMD, ROCm, HIP, CUDA, C++ language extensions
*******************************************************************************
Programming Model
*******************************************************************************
HIP defines a model of mapping SIMT programs (Single Instruction, Multiple
Threads) onto various architectures, primarily GPUs. While the model may be
expressed in most imperative languages, (eg. Python via PyHIP) this document
will focus on the original C/C++ API of HIP.
Threading Model
===============================================================================
The SIMT nature of HIP is captured by the ability to execute user-provided
device programs, expressed as single-source C/C++ functions or sources compiled
online/offline to binaries in bulk.
Multiple instances of the device program (aka. kernel) may execute in parallel,
all uniquely identified by a set of integral values which are referred to as
thread IDs. The set of integers identifying a thread relate to the hierarchy in
which threads execute.
.. _inherent_thread_model:
Inherent Thread Model
-------------------------------------------------------------------------------
The thread hiearchy inherent to how AMD GPUs operate manifest as depicted in
:numref:`inherent_thread_hierarchy`.
.. _inherent_thread_hierarchy:
.. figure:: ../data/reference/programming_model/thread_hierarchy.svg
:alt: Diagram depicting nested rectangles of varying color. The outermost one
titled "Grid", inside sets of uniform rectangles layered on oneanother
titled "Block". Each "Block" containing sets of uniform rectangles
layered on oneanother titled "Warp". Each of the "Warp" titled
rectangles filled with downward pointing arrows inside.
Hierarchy of thread groups.
* The innermost grouping is called a warp, or a wavefront in ISA terms. A warp
is the most tightly coupled groups of threads, both physically and logically.
When referring to threads inside a warp, they may be called lanes, and the
integral value identifying them the lane ID. Lane IDs aren't quieried like
other thread IDs, but are user-calculated. As a consequence they are only as
multi-dimensional as the user interprets the calculated values to be.
The size of a warp is architecture dependent and always fixed. Warps are
signified by the set of communication primitives at their disposal, detailed
under :ref:`warp_cross_lane_functions`.
* The middle grouping is called a block or thread block. The defining feature
of a block is that all threads in a block will share an instance of memory
which they may use to share data or synchronize with oneanother.
The size of a block is user-configurable but is maxmized by the queryable
capabilites of the executing hardware. The unique ID of the thread within a
block is 3-dimensional as provided by the API. When linearizing thread IDs
within a block, assume the "fast index" being dimension ``x``, followed by
the ``y`` and ``z`` dimensions.
* The outermost grouping is called a grid. A grid manifests as a single
dispatch of kernels for execution. The unique ID of each block within a grid
is 3-dimensional, as provided by the API and is queryable by every thread
within the block.
Cooperative Groups Thread Model
-------------------------------------------------------------------------------
The Cooperative Groups API introduces new APIs to launch, group, subdivide,
synchronize and identify threads, as well as some predefined group-collective
algorithms, but most importantly a matching threading model to think in terms
of. It relaxes some of the restrictions of the :ref:`inherent_thread_model`
imposed by the strict 1:1 mapping of architectural details to the programming
model.
The rich set of APIs introduced by Cooperative Groups allow the programmer
to define their own groups based on run-time predicates, but a set of implicit
groups manifest based on kernel launch parameters.
The thread hiearchy abstraction of Cooperative Groups manifest as depicted in
:numref:`coop_thread_hierarchy`.
.. _coop_thread_hierarchy:
.. figure:: ../data/reference/programming_model/thread_hierarchy_coop.svg
:alt: Diagram depicting nested rectangles of varying color. The outermost one
titled "Grid", inside sets of different sized rectangles layered on
oneanother titled "Block". Each "Block" containing sets of uniform
rectangles layered on oneanother titled "Warp". Each of the "Warp"
titled rectangles filled with downward pointing arrows inside.
Cooperative group thread hierarchy.
* Multi Grid is an abstraction of potentially multiple simultaneous launches of
the same kernel over multiple devices. Grids inside a multi device kernel
launch need not be of uniform size, thus allowing taking into account
different device capabilities and preferences.
.. deprecated:: 5.0
* Same as the :ref:`inherent_thread_model` Grid entity. The ability to
synchronize over a grid requires the kernel to be launched using the
Cooperative Groups API.
* The defining feature of a cluster or block cluster is that all threads in a
cluster will share a common set of distributed shared memory which they may
use to share data or synchronize with oneanother.
* Same as the :ref:`inherent_thread_model` Block entity.
.. note::
Explicit warp-level thread handling is absent from the Cooperative Groups API.
In order to exploit the known hardware SIMD width on which built-in
functionality translates to simpler logic, one may use the group partitioning
part of the API, typically but not necessarily ``tiled_partition``.
Memory Model
===============================================================================
The hierarchy of threads introduced by :ref:`inherent_thread_model` is induced
by the memory subsystem of GPUs. :numref:`memory_hierarchy` summarizes that memory namespaces and
how they relate to the various levels of the threading model.
.. _memory_hierarchy:
.. figure:: ../data/reference/programming_model/memory_hierarchy.svg
:alt: Diagram depicting nested rectangles of varying color. The outermost one
titled "Grid", inside on the upper half a rectangle titled "Cluster".
Inside it are two identical rectangles titled "Block", inside them are
ones titled "Local" with multiple "Warp" titled rectangles. Blocks have
not just Local inside, but also rectangles titled "Shared". The Shared
rectangles of Blocks in the same Cluster are grouped together with a
translucent halo titled "Cluster shared". Outside the Cluster but
inside the Grid is a rectangle titled "Global" with three others
inside: "Surface", "Texture" (same color) and "Constant" (different
color).
Memory hierarchy.
* Local or per-thread memory is read-write storage only visible to the
threads defining the given variables. The size of a block for a given kernel,
the number of concurrent warps are limited by local memory usage.
This relates to an important aspect: occupancy. This is the default memory
namespace.
* Shared memory is read-write storage visible to all the threads in a given
block.
* Distributed shared memory is read-write storage visible to all the threads
in a given block cluster.
* Global memory is read-write storage visible to all threads in a given grid.
There are specialized versions of global memory with different usage
semantics which are typically backed by the same hardware storing global.
* Constant memory is read-only storage visible to all threads in a given
grid. It is a limited segment of global with queryable size.
* Texture memory is read-only storage visible to all threads in a given grid
and accessible through additional APIs.
* Surface is a writable version of texture memory.
Execution Model
===============================================================================
HIP programs consist of two distinct scopes:
* The host-side API running on the host processor. There are to APIs available:
* The HIP runtime API which enables use of the single-source programming
model.
* The HIP driver API which sits at a lower level and most importantly differs
by removing some of the facilities provided by the runtime API, most
importantly around kernel launching and argument setting. It is geared
towards implementing abstractions atop, such as the runtime API itself.
* The device-side kernels running on GPUs. Both the host and the device-side
APIs have synchronous and asynchronous functions in them.
Host-side execution
-------------------------------------------------------------------------------
The part of the host-side API which deals with device management and their
queries are synchronous. All asynchronous APIs, such as kernel execution, data
movement and potentially data allocation/freeing all happen in the context of
device streams.
Streams are FIFO buffers of commands to execute relating to a given device.
Commands which enqueue tasks on a stream all return promptly and the command is
executed asynchronously. All side-effects of a command on a stream are visible
to all subsequent commands on the same stream. Multiple streams may point to
the same device and those streams may be fed from multiple concurrent host-side
threads. Execution on multiple streams may be concurrent but isn't required to
be.
Asynchronous APIs involving a stream all return a stream event which may be
used to synchronize the execution of multiple streams. A user may enqueue a
barrier onto a stream referencing an event. The barrier will will block until
the command related to the event does not complete, at which point all
side-effects of the command shall be visible to commands following the barrier,
even if those side-effects manifest on different devices.
Streams also support executing user-defined functions as callbacks on the host.
The stream will not launch subsequent commands until the callback completes.
Device-side execution
-------------------------------------------------------------------------------
The SIMT programming model behind the HIP device-side execution is a
middle-ground between SMT (Simultaneous Multi-Threading) programming known from
multi-core CPUs, and SIMD (Single Instruction, Multiple Data) programming
mostly known from exploiting relevant instruction sets on CPUs (eg.
SSE/AVX/Neon).
A HIP device compiler maps our SIMT code written in HIP C++ to an inherently
SIMD architecture (like GPUs) not by exploiting data parallelism within a
single instance of a kernel and spreading identical instructions over the SIMD
engines at hand, but by scalarizing the entire kernel and issuing the scalar
instructions of multiple kernel instances to each of the SIMD engine lanes.
Kernel launch
-------------------------------------------------------------------------------
Kernels may be launched in multiple ways all with different syntaxes and
intended use-cases.
* Using the triple-chevron ``<<<...>>>`` operator on a ``__global__`` annotated
function.
* Using ``hipLaunchKernelGGL()`` on a ``__global__`` annotated function.
.. tip::
This name by default is a macro expanding to triple-chevron. In cases where
language syntax extensions are undesirable, or where launching templated
and/or overloaded kernel functions define the
``HIP_TEMPLATE_KERNEL_LAUNCH`` preprocessor macro before including the HIP
headers to turn it into a templated function.
* Using the
:doxygen:`launch APIs supporting the triple-chevron syntax <Clang>` directly.
.. caution::
These APIs are intended to be used/generated by tools such as the HIP
compiler itself and not intended towards end-user code. Should you be
writing a tool having to launch device code using HIP, consider using these
over the alternatives.
docs/sphinx/requirements.in
+2 -1
Просмотреть файл
@@ -1 +1,2 @@
rocm-docs-core[api_reference]>=0.30.3
rocm-docs-core[api_reference]>=0.36.0
sphinxcontrib.doxylink
docs/sphinx/requirements.txt
+12 -12
Просмотреть файл
@@ -1,8 +1,8 @@
#
# This file is autogenerated by pip-compile with Python 3.8
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
# pip-compile requirements.in
# pip-compile ./docs/sphinx/requirements.in
#
accessible-pygments==0.0.3
# via pydata-sphinx-theme
@@ -53,10 +53,6 @@ idna==3.3
# via requests
imagesize==1.4.1
# via sphinx
importlib-metadata==7.0.1
# via sphinx
importlib-resources==6.1.1
# via rocm-docs-core
jinja2==3.1.3
# via
# myst-parser
@@ -107,6 +103,9 @@ pyparsing==3.0.9
# via
# doxysphinx
# packaging
# sphinxcontrib-doxylink
python-dateutil==2.9.0.post0
# via sphinxcontrib-doxylink
pytz==2022.1
# via babel
pyyaml==6.0
@@ -118,8 +117,10 @@ requests==2.31.0
# via
# pygithub
# sphinx
rocm-docs-core[api_reference]==0.30.3
# via -r requirements.in
rocm-docs-core[api-reference]==0.36.0
# via -r ./docs/sphinx/requirements.in
six==1.16.0
# via python-dateutil
smmap==5.0.0
# via gitdb
snowballstemmer==2.2.0
@@ -137,6 +138,7 @@ sphinx==5.3.0
# sphinx-design
# sphinx-external-toc
# sphinx-notfound-page
# sphinxcontrib-doxylink
sphinx-book-theme==1.0.1
# via rocm-docs-core
sphinx-copybutton==0.5.1
@@ -151,6 +153,8 @@ sphinxcontrib-applehelp==1.0.2
# via sphinx
sphinxcontrib-devhelp==1.0.2
# via sphinx
sphinxcontrib-doxylink==1.12.3
# via -r ./docs/sphinx/requirements.in
sphinxcontrib-htmlhelp==2.0.0
# via sphinx
sphinxcontrib-jsmath==1.0.1
@@ -167,7 +171,3 @@ urllib3==1.26.18
# via requests
wrapt==1.15.0
# via deprecated
zipp==3.17.0
# via
# importlib-metadata
# importlib-resources
docs/understand/programming_model.rst
+158
Просмотреть файл
@@ -0,0 +1,158 @@
.. meta::
:description: This chapter explains the HIP programming model, the contract
between the programmer and the compiler/runtime executing the
code, how it maps to the hardware.
:keywords: AMD, ROCm, HIP, CUDA, API design
*******************************************************************************
Programming Model
*******************************************************************************
The HIP programming model makes it as easy as reasonably possible to map
data-parallel C/C++ algorithms and map them to massively parallel, wide SIMD
architectures, such as GPUs. As a consequence, one needs a basic understanding
of the underlying device architecture to make efficient use of HIP and GPGPU
(General Purpose Graphics Processing Unit) programming in general.
RDNA & CDNA Architecture Summary
===============================================================================
Most GPU architectures, much like RDNA and CDNA have a hierarchical structure.
The inner-most piece is some Single Instruction Multiple Data (SIMD) enabled
vector Arithmetic Logical Unit (ALU). Most recent GPUs beside the vector ALU
also house some matrix ALU for accelerating algorithms of well defined shapes.
Some number of vector and matrix ALUs comprise a larger block, often referred
to as a Compute Unit (OpenCL, AMD block diagrams) but is referred to as Multi
Processor in HIP terms.
.. _rdna3_cu:
.. figure:: ../data/understand/programming_model/rdna3_cu.png
:alt: Block diagram showing components mostly duplicated on the upper and
lower halves of the image with some spanning over both parts (hinting
at them being shared). Both the top and the bottom have two sets of
identical hardware blocks. a "Scheduler" having "Vector GPR"s with an
associated Vector ALU with the following noted capabilities:
Float/INT/Matrix SIMD32, Float/Matrix SIMD32, Transcendental SIMD8, AI
MATRIX Accelerator, DPFP (1). Both top and bottom have a single "Ray
Accelerator", "Texture Filters" and "LD/ST/Tex Addr" and L0 blocks.
Shared among top and bottom are "Scalar Cache", "Shader Instruction
Cache" and Shared Memory.
Block Diagram of an RDNA3 Compute Unit.
.. _cdna3_cu:
.. figure:: ../data/understand/programming_model/cdna3_cu.png
:alt: Block diagram showing components: "Scheduler", "Local Data Share",
"Matrix Core Unit", "Shader Core" and "L1 Cache" along with some
unnamed blocks.
Block Diagram of an CDNA3 Compute Unit.
For hardware implementation's sake, some number of Multi Processors are grouped
together into a Shader Engine or Compute Engine, typically sharing some fixed
function units or memory subsystem resources.
.. _cdna2_gcd:
.. figure:: ../data/understand/programming_model/cdna2_gcd.png
:alt: Block diagram showing four "Compute Engine"s each with 28 "CU"s
(Compute Unit) inside. These four Compute Engines share one block of
"L2 Cache and Controllers". Around them are four "Memory Controller"s,
each having a "Memory Phy" block next to them. To the top and bottom of
all these are eight blocks of "Infinity Fabric Link" with one of the
eight reading "Infinity Fabric or PCIe". Two sole "VCN" blocks sit in
top corners. At the very bottom spans a colored seaction reading
"Infinity Fabric" along with its logo.
Block Diagram of a CDNA2 Graphics Compute Die.
Single Instruction Multiple Threads
===============================================================================
The SIMT programming model behind the HIP device-side execution is a
middle-ground between SMT (Simultaneous Multi-Threading) programming known from
multi-core CPUs, and SIMD (Single Instruction, Multiple Data) programming
mostly known from exploiting relevant instruction sets on CPUs (eg.
SSE/AVX/Neon).
A HIP device compiler maps our SIMT code written in HIP C++ to an inherently
SIMD architecture (like GPUs) not by exploiting data parallelism within a
single instance of a kernel and spreading identical instructions over the SIMD
engines at hand, but by scalarizing the entire kernel and issuing the scalar
instructions of multiple kernel instances to each of the SIMD engine lanes.
Consider the following kernel
.. code:: cu
__global__ void k(float4* a, const float4* b)
{
int tid = threadIdx.x;
int bid = blockIdx.x;
int dim = blockDim.x;
a[tid] += (tid + bid - dim) * b[tid];
}
The incoming four-vector of floating-point values ``a`` is multiplied by a
scalar and then multiplied element-wise by another four-vector. On modern
SIMD-capable architectures the four-vector ops are expected to compile to a
single SIMD instruction. GPU execution of this kernel however will typically
look the following:
.. _simt:
.. figure:: ../data/understand/programming_model/simt.svg
:alt: Two large arrows pointing downward with blocks inside and ellipses
between the arrows. Inside the arrows the same series of blocks with
the following texts inside from top to bottom: "ADD", "DIV", "FMA",
"FMA", "FMA" and "FMA".
Instruction flow of the sample SIMT program.
In HIP, lanes of a SIMD architecture are fed by mapping threads of a SIMT
execution, one thread down each lane of a SIMD engine. Execution parallelism
isn't exploited from the width of the built-in vector types, but via the thread
id constants ``threadIdx.x``, ``blockIdx.x``, etc. For more details, refer to
:ref:`inherent_thread_model`.
Heterogenous Programming
===============================================================================
The HIP programming model assumes two execution contexts. One is referred to as
*host* while compute kernels execute on a *device*. These contexts have
different capabilities, therefor slightly different rules apply. The *host*
execution is defined by the C++ abstract machine, while *device* execution
follows the HIP model, primarily defined by SIMT. These execution contexts in
code are signified by the ``__host__`` and ``__device__`` decorators. There are
a few key differences between the two:
* The C++ abstract machine assumes a unified memory address space, meaning that
one can always access any given address in memory (assuming the absence of
data races). HIP however introduces several memory namespaces, an address
from one means nothing in another. Moreover not all address spaces are
accessible from all contexts.
If one were to look at {ref}`cdna2_gcd` and inside the {ref}`cdna3_cu`,
every Compute Unit has an instance of storage backing the namespace
``__shared__``. Even if the host were to have access to these regions of
memory, the performance benefits of the segmented memory subsystem are
supported by the inability of meaningful asynchronous accesss from the host.
* Not all C++ language features map cleanly to typical device architectures,
some are very expensive (meaning: slow) to implement on GPU devices, therefor
they are forbidden in device contexts to avoid users tapping into features
unexpectedly decimating their program's performance. Offload devices targeted
by HIP aren't general purpose devices, at least not in the sense a CPU is.
HIP focuses on data parallel computations and as such caters to throughput
optimized architectures, such as GPUs or accelerators derived from GPU
architectures.
* Asynchrony is at the forefront of the HIP API. Computations launched by HIP
execute asynchronously on the device and it is the user's responsibility to
synchronize their data dispatch/fetch with computations on the device. HIP
does perform implicit synchronization on occasions, but unlike some APIs
(OpenCL, SYCL) by and large places the onus of synchronization on the user.
include/hip/hip_runtime_api.h
+9 -9
Просмотреть файл
@@ -2375,7 +2375,7 @@ hipError_t hipDrvGetErrorString(hipError_t hipError, const char** errorString);
* Create a new asynchronous stream. @p stream returns an opaque handle that can be used to
* reference the newly created stream in subsequent hipStream* commands. The stream is allocated on
* the heap and will remain allocated even if the handle goes out-of-scope. To release the memory
* used by the stream, applicaiton must call hipStreamDestroy.
* used by the stream, application must call hipStreamDestroy.
*
* @return #hipSuccess, #hipErrorInvalidValue
*
@@ -2392,7 +2392,7 @@ hipError_t hipStreamCreate(hipStream_t* stream);
* Create a new asynchronous stream. @p stream returns an opaque handle that can be used to
* reference the newly created stream in subsequent hipStream* commands. The stream is allocated on
* the heap and will remain allocated even if the handle goes out-of-scope. To release the memory
* used by the stream, applicaiton must call hipStreamDestroy. Flags controls behavior of the
* used by the stream, application must call hipStreamDestroy. Flags controls behavior of the
* stream. See #hipStreamDefault, #hipStreamNonBlocking.
*
*
@@ -2410,7 +2410,7 @@ hipError_t hipStreamCreateWithFlags(hipStream_t* stream, unsigned int flags);
* Create a new asynchronous stream with the specified priority. @p stream returns an opaque handle
* that can be used to reference the newly created stream in subsequent hipStream* commands. The
* stream is allocated on the heap and will remain allocated even if the handle goes out-of-scope.
* To release the memory used by the stream, applicaiton must call hipStreamDestroy. Flags controls
* To release the memory used by the stream, application must call hipStreamDestroy. Flags controls
* behavior of the stream. See #hipStreamDefault, #hipStreamNonBlocking.
*
*
@@ -2428,7 +2428,7 @@ hipError_t hipStreamCreateWithPriority(hipStream_t* stream, unsigned int flags,
* and greatest stream priority respectively. Stream priorities follow a convention where lower numbers
* imply greater priorities. The range of meaningful stream priorities is given by
* [*greatestPriority, *leastPriority]. If the user attempts to create a stream with a priority value
* that is outside the the meaningful range as specified by this API, the priority is automatically
* that is outside the meaningful range as specified by this API, the priority is automatically
* clamped to within the valid range.
*/
hipError_t hipDeviceGetStreamPriorityRange(int* leastPriority, int* greatestPriority);
@@ -2500,8 +2500,8 @@ hipError_t hipStreamSynchronize(hipStream_t stream);
* All future work submitted to @p stream will wait until @p event reports completion before
* beginning execution.
*
* This function only waits for commands in the current stream to complete. Notably,, this function
* does not impliciy wait for commands in the default stream to complete, even if the specified
* This function only waits for commands in the current stream to complete. Notably, this function
* does not implicitly wait for commands in the default stream to complete, even if the specified
* stream is created with hipStreamNonBlocking = 0.
*
* @see hipStreamCreate, hipStreamCreateWithFlags, hipStreamCreateWithPriority, hipStreamSynchronize, hipStreamDestroy
@@ -3351,7 +3351,7 @@ hipError_t hipStreamAttachMemAsync(hipStream_t stream,
*
* Inserts a memory allocation operation into @p stream.
* A pointer to the allocated memory is returned immediately in *dptr.
* The allocation must not be accessed until the the allocation operation completes.
* The allocation must not be accessed until the allocation operation completes.
* The allocation comes from the memory pool associated with the stream's device.
*
* @note The default memory pool of a device contains device memory from that device.
@@ -3603,7 +3603,7 @@ hipError_t hipMemPoolDestroy(hipMemPool_t mem_pool);
*
* Inserts an allocation operation into @p stream.
* A pointer to the allocated memory is returned immediately in @p dev_ptr.
* The allocation must not be accessed until the the allocation operation completes.
* The allocation must not be accessed until the allocation operation completes.
* The allocation comes from the specified memory pool.
*
* @note The specified memory pool may be from a device different than that of the specified @p stream.
@@ -6305,7 +6305,7 @@ hipError_t hipGetTextureAlignmentOffset(
DEPRECATED(DEPRECATED_MSG)
hipError_t hipUnbindTexture(const textureReference* tex);
/**
* @brief Gets the the address for a texture reference.
* @brief Gets the address for a texture reference.
*
* @param [out] dev_ptr Pointer of device address.
* @param [in] texRef Pointer of texture reference.