Issue: Header uses std::vector<Agent_global> agent_globals which is created by hip_module.cpp
- Move iterator fails to copy Agent_global from library source into header version
- Due to different versions of std::string name in struct Agent_global
Fix: Change Agent_global to use char* name instead of std::string name
[ROCm/clr commit: fcde9fe3df]
Issue: mismatch undefined symbols in different user env
- Binary expects modified return value std::string&
- Fails to match libhip_hcc.so: return value is std::string& but doesn't match modified C++ env
Fix: Change return value to char*, create new key std::string in header from char*
[ROCm/clr commit: f8aca3159c]
* 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.
[ROCm/clr commit: ed48847237]
Add 2 extra memset functions which fills memory with integer-typed data
Also change the parameters of ihipMemset to better explain the semantic
[ROCm/clr commit: 392271f4db]
The implementation is copied from HCC runtime.
For hcc it has no effect since apps can find them in either hcc runtime or HIP
runtime.
hip-clang needs it in HIP/HCC runtime so that HIP/HCC and HIP/VDI runtime are
swappable.
[ROCm/clr commit: 972ca06c4c]
A hash calculated via FNV-1a algorithm is introduced in ihipModule_t, the
internal of hipModule_t. The hash is used by HIP module APIs such as
- read_agent_global_from_module
to determine whether the agent-scope globals for a module have been iterated.
This commit fixes one issue that applications which load / unload modules
frequently would occasionally fail. After deep investigation of the issue it
turns out the old implementation in read_agent_global_from_module uses
hipModule_t as the key, which is not robust enough, as hipModule_t instances
are allocated dynamically so there are cases that one memory address may be
used by multiple hipModule_t instances. The real solution is to introduce a
uniquely identifiable hash for the code object associated with the HIP module.
And that's the rationale behind this commit.
[ROCm/clr commit: 6e68d44220]
The logic to parse the kernel metadata is unaware that enabling
of early finalization could result in multiple code blobs in a
single .kernel section. This teaches the HIP runtime to handle
that.
Change-Id: I1581b42f0da8b30233d7898014f7468728c1d489
[ROCm/clr commit: ba2b5ff9da]
Siu Chi Chan
Aaron Enye Shi
Maneesh Gupta
Alex Voicu
Rahul Garg
Wen-Heng (Jack) Chung
Wilkin Chau
Yaxun Sam Liu
lmoriche
Laurent Morichetti
Rahul Garg
Evgeny
Qianfeng Zhang
Michael Kuron
root