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

Documentation review and update

Browse Source 
Change-Id: If40d096646014d70a198db3532758028abe6a93f


[ROCm/hip commit: b1b099941d]
This commit is contained in:
Ben Sander
2016-09-02 09:15:49 -05:00
parent cac6e516ac
commit 3f22169885
4 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
projects/hip/docs/markdown/hip_performance.md
+3 -6
View File
@@ -12,7 +12,7 @@ There are two possible ways to transfer data from Host to Device (H2D) and Devic
#### On Large BAR Setup
There are two possible ways to transfer data from Host to Device (H2D)
There are three possible ways to transfer data from Host to Device (H2D)
* Using Staging Buffers
* Using PinInPlace
* Direct Memcpy
@@ -24,12 +24,9 @@ There are two possible ways to transfer data from Host to Device (H2D)
Some GPUs may not be able to directly access host memory, and in these cases we need to
stage the copy through an optimized pinned staging buffer, to implement H2D and D2H copies.The copy is broken into buffer-sized chunks to limit the size of the buffer and also to provide better performance by overlapping the CPU copies with the DMA copies.
PinInPlace is another algorithm which pins the host memory "in-place", and copies it with the DMA
engine.
PinInPlace is another algorithm which pins the host memory "in-place", and copies it with the DMA engine.
By default staging buffers are used for unpinned memory transfers, however other ways can be used by enabling few environment variables (so no need to build the code again!!!)
Following environment variables can be used:
By default staging buffers are used for unpinned memory transfers. Environment variables allow control over the unpinned copy algorithm and parameters:
- HIP_PININPLACE - This environment variable forces the use of PinInPlace logic for all unpinned memory copies