AI/rocm-systems
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix various typos

Browse Source 
Conflicts:
	README.md

Change-Id: Ie296d503d16121a62fed1a208352ec2b81c97fd9


[ROCm/hip commit: 263dcfed83]
This commit is contained in:
Martin Schleiss
2016-12-14 00:13:30 +01:00
committed by Maneesh Gupta
parent beb82e5109
commit d3ca48fc45
7 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
projects/hip/docs/markdown/hip_porting_driver_api.md
+3 -3
View File
@@ -31,8 +31,8 @@ accelerator language front-end. Here, NVCC is not used. Instead, the environm
different kernel language or different compilation flow.
Other environments have many kernels and do not want them to be all loaded automatically.
The Module functions can be used to load the generated code objects and launch kernels.
As we will see below, HIP defines a Module API which provides similar explict control over code
object managemenet.
As we will see below, HIP defines a Module API which provides similar explicit control over code
object management.
### cuCtx API
The Driver API defines "Context" and "Devices" as separate entities.
@@ -144,7 +144,7 @@ table shows the type equivalence to enable this interaction.
The hipModule interface does not support the hipModuleLoadEx function, which is used to control PTX compilaton options.
HCC does not use PTX and does not support the same compilation options.
In fact, HCC code objects always contain fully compiled ISA and do not require additional compilation as part of the load step.
Code which requires this functionaly should use platform-specific coding, calling `cuModuleLoadEx`
Code which requires this functionally should use platform-specific coding, calling `cuModuleLoadEx`
on the NVCC path and hipModuleLoad on the hcc path. For example:
```