8 Коммитов

Автор	SHA1	Сообщение	Дата
Alex Voicu	abe3c22cf1	This is primarily intended as an additional cleanup of the module functionality, in the aftermath of adopting module based dispatch. The main effort was associated with refactoring the questionable ihipModuleGetSymbol. It was quaintly written and misleading, in that it had little to do with getting symbols, and was exactly retrieving a kernel object. Error handling is modified so as to reduce branching depth. Functions which serve as interfaces to the HSA RT are moved in a separate helper header. Code object readers are properly deleted. Some leftover dead functionality pertaining to associating namespace scope variables with their allocated memory is removed. Executable loading is changed to use a string which holds the ELF image of the code object being loaded, thus avoiding some corner cases where using a istream would fail. ... [ROCm/hip commit: 5127ce67e8]	2017-12-03 23:09:06 +00:00
Alex Voicu	08a0d96448	Fix legacy mode detection of the address of an agent allocated variable. In this mode, there exist two executables per each code object, one created by HCC and one created by HIP. Since we dispatch through HCC in legacy mode, we should obtain the address for an agent allocated variable from the latter's executable. Also add two omitted validity checks, whose absence could lead to segfaults when the current process had no .kernel section and / or when an invalid or empty blob was extracted from the latter. ... [ROCm/hip commit: 7c0b9a005b]	2017-11-30 03:29:04 +00:00
Alex Voicu	aef26d3477	Re-sync with upstream and re-factor platform global management for texture references. ... [ROCm/hip commit: 02c2bfc7ef]	2017-11-28 19:15:29 +00:00
Alex Voicu	d71132de7c	This corrects how addresses are formed for symbols which reside in shared objects. For this case, the .value component of an ELF symbol holds the offset from the base VA where the shared object was loaded. Thus, to correctly obtain the VA of the object refered by the symbol, we must add the offset to the VA where the shared object is loaded. We were already doing this correctly for symbols denoting functions, but we were incorrect for those denoting objects. ... [ROCm/hip commit: 5e16ee0d1f]	2017-11-21 13:15:13 +00:00
Alex Voicu	45ff3c31c4	Refactor the __device__ versions of memset and memcpy to be less awkward i.e. not return nullptr as opposed to the destination pointer (it can only be assumed it was done for maximum confusion) and actually unroll as they claim to. Change all of the {to, from}Symbol functions to use hipModuleGetGlobal, as opposed to hc::accelerator::get_symbol_address which is no longer valid with module based dispatch. ... [ROCm/hip commit: 9d088d2283]	2017-11-21 02:40:34 +00:00
Alex Voicu	e8ca14848e	Clean-up some remaining noise in program_state.cpp. ... [ROCm/hip commit: 1824fb7698]	2017-11-20 22:41:46 +00:00
Alex Voicu	dab971370e	Correctly deal with functions from shared objects, wherein the program visible VA == so_base_va + st_value(function_symbol). Remove quaint usage of pfe for hipMemset (which is actually fill_n). ... [ROCm/hip commit: 2cacda91bb]	2017-11-01 22:33:13 +00:00
Alex Voicu	70a41e7dac	This switches HIP from its currently convoluted macro + pfe based dispatch mechanism to a more natural one partially based on the existing module API. The basic idea is that HCC will always correctly emit __global__ functions: as empty-bodied stubs, on host, and as kernels, on device. It then becomes trivial to obtain the mangled name on host, at dispatch, from the function's address, and then to use the mangled name to retrieve the kernel. This should address all problems stemming from serialisation, dubious mismatches due to the manufactured functor, macro-isms et al. It also immediately enables support for generalised globals as a consequence of that being available in the module API. Finally, it will make debug much easier, since the actual names of the __global__ functions will automatically be used in traces etc. One detail is that due to how dispatch works now (hipLaunchKernel and hipLaunchKernelGGL are themselves variadic function templates which deduce the function type of the callee), in certain cases it may be necesssary to insert explicit casts to ensure that the variadic argument list selects a viable overload - this can be observed in some unit tests. Eventually we may be able to remove this limitation, but for now it does not appear terribly onerous. The code is not extremely HIPpie, nor is it fully optimised, but rather is intended as a starting point for the HIP team to make its own. ... [ROCm/hip commit: c2482d1255]	2017-11-01 15:09:59 +00:00