* all thread local access now through single struct
* clean up old commented-out code, more use of GET_TLS()
* fewer calls to GET_TLS by passing tls as a funtion argument
* revert unnecessary change to printf
* fix failing tests due to TLS change
* fix merge conflicts in ihipOccupancyMaxActiveBlocksPerMultiprocessor
[Reason] To be compatible with CUDA [#1133]
Update HIP code, hipify-clang, tests and docs
[TODO] Add support of the corresponding functions on nvcc fallback path
+ Makes hip_Memcpy2D struct compatible with CUDA_MEMCPY2D struct
+ Add hipMemcpyParam2D support in nvcc fallback path
+ Update hipify-clang, tests and docs accordingly
* In hipFree, if memory is associated with a device, synchronize that device's streams.
This changes the behavior from synchronizing the currently set TLS device.
* All devices sync in hipFree for _appId=-1 case.
* Revert "All devices sync in hipFree for _appId=-1 case."
This reverts commit 1efb34d6a8426661e45bc5f763422a1147aeac10.
* add HIP_SYNC_FREE env var
* Initial attempt to switch over to internally linked state.
* Add missing CMake update.
* hipLaunchKernelGGLImpl must be inline as well. Ensure internal linkage.
* Ensure global retrieval uses internally linked state.
* Hide HC in the implementation. Minimise ADL woes.
* Strange software exists, and must be catered to.
* Use a less spammy mechanism for ensuring internal linkage / non-export.
* Remove leftover internal detail.
from a header into a source file such that
there's only an unique copy in an executable
and prevent wasting static memory on the host
Change-Id: Id5b62766f77809c8d7b47892cb7149c490dcbdb9
When shareWithAll memory (e.g., host memory) is allocated, set appId
in hc::AmPointerInfo to -1 to indicate that this memory is not mapped
to any device. Peer checking in ihipStream_t::canSeeMemory is not
necessary if memory is shared with all devices. Thus, it is skipped.
Note that earlier host memory is always mapped to device 0 and HIP
always performs peer checking for all kinds of hipMemcpy. Since the
peer checking process requires context locking, hipMemcpy from/to host
memory always grabs device 0's context lock. Therefore, if there is
another thread holding the context lock of device 0 (e.g.,
hipDeviceSynchronize on device 0), hipMemcpy will have to wait for the
lock until it can actually perform memcpy. This can significantly
deteriorate execution performance.
Signed-off-by: Sarunya Pumma <sarunya.pumma@amd.com>
Rahul Garg
Jatin Chaudhary
Jeff Daily
Rahul Garg
Evgeny Mankov
Anusha Godavarthy Surya
Maneesh Gupta
Alex Voicu
Wen-Heng (Jack) Chung
Wilkin Chau
Evgeny
Michael Kuron
Michael Kuron
Siu Chi Chan
Anton Gorenko
Sarunya Pumma