By default hipcc passes -mllvm options to let HIP-Clang inline all device functions.
--hipcc-func-supp enables function support and disables inline all.
--hipcc-no-func-supp disable function support and enables inline all.
This is a temporary solution to match HCC behavior for performance.
This option is mainly for debugging purpose.
Change-Id: I0c44ac1812bb3cea5c3e5b6e14ebaa45919236f6
[ROCm/clr commit: 2198aead38]
* Fix cooperative launch APIs to set hipGetLastError
Previously, the cooperative launch APIs did not properly log their
errors in the global hipGetLastError variable before returning back
to the user. As such, the APIs would leave hipSuccess in the
last error, which would break some use cases.
This fixes that problem by making a trampoline function that does
the HIP_INIT_API and ihipLogStatus.
* Add missing flag to the log of multi-GPU launch
[ROCm/clr commit: 341ef7fdca]
The hipExtModuleLaunchKernel and hipModuleLoadDataMultiThreaded tests keeps randomly failing on Jenkins.
Change-Id: I87e5d54fb7429c14ff1dcecb20e03a7816670fae
[ROCm/clr commit: 684cdd4a18]
Change-Id: If419d2fad490d0ed50eb1315af809fc1deda1ce3
SWDEV-227875: Add a lock in streams to lock when the callback is call so we make sure things aren't moving forward in the stream
[ROCm/clr commit: 9f81498bb5]
Change-Id: I1f107fc8a5c586cd571f0280ed8716c5f89d25b7
SWDEV-227875: Need to add a dummy marker in case the stream is empty.
[ROCm/clr commit: 31df9b358d]
nvcc treats .c program as C program and .cpp program as C++ program.
Currently hipcc treats .c and .cpp programs as HIP programs.
It is desirable to let hipcc behave like nvcc.
Currently it is not feasible to let hipcc treat .cpp programs as C++ program
since there are too many HIP applications use .cpp as extension for HIP programs.
However we should be able let hipcc treat .c program C program since there
are few applications use .c as extensioin for HIP programs.
[ROCm/clr commit: 31d9ea89f1]
Addresses an installation problem for several HIP packages.
Packages builds have been tested locally, validation in progress.
[ROCm/clr commit: d90a0c05c0]
What Cuda refers to "linear texture memory" is the OpenCL equivalent of CL_MEM_OBJECT_IMAGE1D_BUFFER. For these types of allocations we should create a typed buffer instead of an image.
Currently there is no check in the texture fetch functions as to what kind of SRD is written into the texture object, so any kind of incorrect programming will cause the TA to hang. Fortunately for us, every one writes correct code :)
Change-Id: I80dab85a992f2c0754ebf303d40ac6b5e045c7c1
[ROCm/clr commit: 78f7954765]
These are artifacts left from HIP-HCC and now are not needed by HIP-VDI.
Change-Id: Ib25a1081fe6146c8a89659395151e9d5bdaf7519
[ROCm/clr commit: 8083935855]
Currently the texture C++ API is forwarded to the ihip*Impl() calls, which are not even a part of Cuda. These should be forwarded to their respective Cuda C APIs instead.
This change also fixes a bug with hipUnbindTexture() creating a dangling pointer.
Change-Id: Ifafc9d106855a11bec84a18ea214b3d89e39990d
[ROCm/clr commit: 53dd6b7a66]
Currently we extract the read mode from the ihip*impl() calls, which is not correct. We should be getting it from the texture itself directly.
Change-Id: Idf6449fefa395a887138a252e8ea937a6897e600
[ROCm/clr commit: 42b149fe3c]
hipBindTextureToMipmappedArray()
The texture reference needs to be passed as a constant pointer.
Change-Id: I6d31204c7f2325a5bc1e8b6e089fd9f8d21d1d78
[ROCm/clr commit: 9731b61a60]
Update the packaging code to be CMake 3.5 compatible for CI. Create two
packages rocm-opencl and rocm-opencl-dev on Ubuntu and CentOS. Add
proper versioning into naming.
Change-Id: I116081b7f6f7efa4be43ab3a66e4d3bff0589298
[ROCm/clr commit: b3d035b1dc]
reinterpret_cast<> doesn't create an object, so the texref is actually unitiliazed. This may lead to garbage data in some of its struct members.
Initialize it by performing a placement new. The constructer should set all of its members to default values. There's no way currently to extract the channel type, so use single channel char for now.
Change-Id: I41b305a75bb3f30130324de785099f55b3e130c7
[ROCm/clr commit: b4a0008b36]
Similar to the previous patch, this change adds type constraints to texture indirect functions. Since we don't have to deduce the return type for these, we simply just have to check if the user provided a valid channel type.
Change-Id: Ia094bd6126e01df2ea90902c9aa59cb6cfe85773
[ROCm/clr commit: 8667e21b25]
When sampling a pixel the hw always returns a float4. The type in the texture reference controls the bitcast that we perform before returning the sampled pixel. Creating a texture with an unsupported will lead to potential UB.
This change makes it so that it's only possible to use textures with a type that makes sense. Using something like texture<int, hipTextureType1D, hipReadModeNormalizedFloat> will now lead to a compilation error with a message "Invalid channel type!".
Change-Id: I7fde44cb1d4b9737e0c48c28cb59c018c59ccaa2
[ROCm/clr commit: a994da8af6]
Evgeny Mankov
Chauncey Hui
Payam Ghafari
Paul Fultz II
Yaxun (Sam) Liu
Joseph Greathouse
jujiang
German Andryeyev
Vladislav Sytchenko
Christophe Paquot
Nick Curtis
Aaron Enye Shi
Saleel Kudchadker
kjayapra-amd
Jeff Daily
nelsonc-amd
Sarbojit Sarkar
Jiabao Xie
Jatin Chaudhary