Support hipLaunchCooperativeKernelMultiDevice()
- Add validation logic for MGPU launches to pass a cuda test
Change-Id: Iccca7fde43493fc3bc6685512d39202271ae3e92
Even though the runtime and driver texture object API is one to one, the structs used by these APIs are not. See hipResourceDesc vs HIP_RESOURCE_DESC differences.
These differences are not trivial and most likely won't be able to handled by hipify, so we need new API entry points.
Change-Id: Id4bcb1ad0ae15378dbdb5a2ed07e5ea30f320082
- Use symbol value as the qeury key. Compared to the symbol name, the
symbol value is more robust as developers may use unqualified or
qualified identifiers. It also removes the mangling and/or demangling
requirement for the runtime API.
Change-Id: I9d4259f3842612c7cc98551269fc2092d8b5c19e
This is cherry-picked from PR#1947 that was committed to the
github repo. It allows printf to work with hip-clang and HCC
runtime.
Change-Id: I754753250ea1e694cf3441722e2d4c9d25fa75bc
This also adds declarations of all the missing texture APIs.
hipTexRefSet*() functions need to take a textureReference as a ptr for type erasure to work. Runtime has been modified to accomodate this.
This change only applies to VDI.
Change-Id: Icf43cc5bd44dfc2c39084b7fe56d5a793bf7319f
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
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
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
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
This change addresses three things.
First the available APIs are brought up to par with Cuda (missing ones are added and incorrect ones removed).
Second the size of hip/hcc_detail/texture_functions.h. Using some template magic we can bring down the code size down from ~11k lines to only ~900 lines in total.
Third this change fixes some bugs in the declaration of the texture fetch funcitons. Currently the return type for textures with read mode set to hipReadModeNormalizedFloat is not float. This causes pixel data to be lost during the bitcast when the texture pixel element size is less than the size of float.
The new headers will only be enabled for VDI to avoid breaking HCC.
Change-Id: I77cb29293fb79e55681be094c37702a48d80b64c
There are now two implementations of printf in HIP:
1. The implemenation for HCC is controlled by the HC_FEATURE_PRINTF
macro, and it works only with the HCC compiler used in combination
with the HCC runtime.
2. The implementation for hip-clang requires the VDI runtime, and is
always enabled with that combination.
Change-Id: Ibaeda7900ffe2ce602ca0094aafed0f1147ac2b6
Fix compilation error on hip-hcc+clang , hip-vdi+clang
Enabled hipExtLaunchMultiKernelMultiDevice test on hip-vdi path
hipExtLaunchMultiKernelMultiDevice common declaration for all paths
Change-Id: I76031840614fce8e12a8e845548fa43a389a741a
Temporarily comment out Hcc-specific template functions
hipExtLaunchKernelGGL and hipOccupancyMaxPotentialBlockSize for CLang
compiler so that all test cases under hip/samples can be built
successfully for Clang + Hip/Hcc runtime.
Change-Id: Iafc761257be4a7b34eafa6759a01f369570cd6ce
* Device texture functions should not normalize the sampled pixel. This is already done by HW.
* Add support to use h/w capability for normalized float data convertion for driver API's
Co-authored-by: ansurya <50609411+ansurya@users.noreply.github.com>
* Add missing texturePitchAlignment member to the hipDeviceProp_t struct.
* Add missing hipDeviceAttributeTexturePitchAlignment enumerator to the hipDeviceAttribute_t enum.
* Initialize texturePitchAlignment to 256. This works for gfx9+, but is technically overaligned in most cases for pre-gfx9.
* Add the texturePitchAlignment property to the NVCC path.
Fixes SWDEV-218626 and SWDEV-218629
Changes:
- Revert "`static inline` in a header, just like excess sugar in a diet, causes bloat (#1692)"
This reverts commit be70b9f7e7.
- Revert "Fix rocFFT build failure (#1777)"
This reverts commit 753277422a.
German Andryeyev
Vladislav Sytchenko
Michael LIAO
Sameer Sahasrabuddhe
Sarbojit Sarkar
Sameer Sahasrabuddhe
Lad, Aditya
agodavar
saleelk
Rahul Garg
Nick Curtis
Tao Sang
ansurya
Aryan Salmanpour
Maneesh Gupta
Alex Voicu
vsytch
satyanveshd
mshivama
kpyzhov
Evgeny Mankov